Re: [RFC] [Feature] In project `configuration.scm` allow dependencies to other repos with `configuration.scm`

[Josh Marshall]

Hello Ludo,

I hadn't found that post, but what I'm trying to get across holds.
Barring distribution of binaries since I don't think that is critical
for improving and incremental adoption of Guix to support
infrastructure. A `manifest.scm` could look like the following,
keeping a close eye on the line containing "(remote-repo-dep URI
GIT-REF)".

```
(use-modules (guix)
 (guix build-system gnu)
 ((guix licenses) #:prefix license:)
 (gnu packages autotools)
 (gnu packages ...)
 (gnu remote-repo-dep-mod)
 (gnu packages ...)
 (gnu packages version-control))

(package
  (name "your-project-name")
  (version "???")
  (source #t)
  (build-system ???)
  (native-inputs
   (append (list autoconf
 ...
 (remote-repo-dep URI GIT-REF)
 ...
 pkg-config)
  (inputs
   (list libffi bash-minimal))
  (propagated-inputs
   (list libunistring libgc))

  (native-search-paths
   (list (search-path-specification
  (variable "GUILE_LOAD_PATH")
  (files '("share/guile/site/3.0")))
 (search-path-specification
  (variable "GUILE_LOAD_COMPILED_PATH")
  (files '("lib/guile/3.0/site-ccache")
  (synopsis "...")
  (description "...")
  (home-page "...")
  (license license:lgpl3+))
```

Now, having that single line as a way to include code as opposed to
what can be accomplished similarly with similar expressiveness for the
purpose of the target user group of researchers (think mechanical
engineers, biologists, electrical labs, chemists) and general
developers would lower the barrier of entry to use Guix and improve
the quality of their projects to the point where it just wouldn't make
sense not to.  Now, since there is such a well developed and
documented workflow for a similar process, would I be wrong in
assuming that such functionality could be relatively easy to
implement?

Let me know if gmail is messing up formatting.  I think something is off.

On Wed, Nov 20, 2024 at 4:45 PM Ludovic Courtès  wrote:
>
> Josh Marshall  skribis:
>
> > This is a technical workaround, not direct support.  If such a feature
> > is to be aimed at general developers and researchers, it can't be so
> > circuitous. The Invocation from any form of Guix installation needs to
> > be `guix shell` and just work.
>
> To make sure we’re talking about the same thing, Efraim is referring to
> the conventions documented at:
>
>   https://guix.gnu.org/cookbook/en/html_node/Software-Development.html
>
> Ludo’.

Re: [RFC] [Feature] In project `configuration.scm` allow dependencies to other repos with `configuration.scm`

[Ludovic Courtès]

Josh Marshall  skribis:

> This is a technical workaround, not direct support.  If such a feature
> is to be aimed at general developers and researchers, it can't be so
> circuitous. The Invocation from any form of Guix installation needs to
> be `guix shell` and just work.

To make sure we’re talking about the same thing, Efraim is referring to
the conventions documented at:

  https://guix.gnu.org/cookbook/en/html_node/Software-Development.html

Ludo’.

Re: Problem building rust application

[David Elsing]

Hi,

Andreas Enge  writes:
> starting phase `build'
> error: failed to select a version for `core-graphics-types`.
> ... required by package `core-graphics v0.23.2`
> ... which satisfies dependency `core-graphics = "^0.23.2"` of package 
> `kanata v1.7.0-prerelease-2 
> (/tmp/guix-build-kanata-1.7.0-prerelease-2.drv-0/kanata-1.7.0-prerelease-2)`
> versions that meet the requirements `^0.1` are: 0.1.1
>
> the package `core-graphics` depends on `core-graphics-types`, with features: 
> `link` but `core-graphics-types` does not have these features.
>
> failed to select a version for `core-graphics-types` which could resolve this 
> conflict
>
> We do have core-graphics-types@0.23.2 and core-graphics-types@0.1.1, so the
> versions look okay to my untrained eye.

it appears that the crates `core-graphics` and `core-graphics-types` are
developed in the same repository [1]. Looking at the commit where the
`core-graphics` version was set to 0.23.2 [2], the
corresponding `core-graphics-types` crate version (0.1.3) already has
the "link" feature, but version 0.1.1 (the version in Guix) does not.
This seems to be a mistake in the `core-graphics` crate.

As `kanata` depends on `core-graphics` version 0.23.2, you should add
a package for rust-core-graphics-types with version 0.1.3 (the latest
0.1.* version) and use that instead in the #:cargo-inputs of
rust-core-graphics-0.23.

Cheers,
David

[1] https://github.com/servo/core-foundation-rs
[2] 
https://github.com/servo/core-foundation-rs/blob/dd284a07f4aec3b78667462cd7ef56d0c6153c68

Re: System log on tty12

[Ludovic Courtès]

Hi,

Felix Lechner via "Development of GNU Guix and the GNU System
distribution."  skribis:

> I played with my virtual consoles and found a system log on tty12. [1]
>
> Having the log there is very convenient.  Plus, the AUTHPRIV facility is
> turned off, and all bets are off anyway when someone gains physical
> access---but is the syslog on tty12 still appropriate now that folks use
> GNU Guix also on production equipment?

I think so.  You explained very clearly why it’s okay, as I see it, at
least by default.

It can be configured anyway, and likewise with Shepherd’s ‘system-log’
service.

WDYT?

Ludo’.

Re: Announcing shepherd-run

[Ludovic Courtès]

Runciter via "Development of GNU Guix and the GNU System distribution."
 skribis:

> I actually think this is cool though, and the rest is mostly random
> thoughts now that I think about this problem: a herd-based minimalist
> alarm clock for production needs 2 features and must not include a third
> feature:
>
> * Repeat, but this is trivial to do with a script.
>
> * A heuristic to output sound at all costs, while trying hard to output
>   through speakers and not headphones. This is harder, maybe not
>   absolutely required; I suppose phones get it right but I'm not
>   even sure.
>
> * A keystroke to stop the alarm from the X lock screen; surely the
>   significant other will close their mind to the truth that this feature
>   increases the attack surface and must not be included.

All good points!  I’d like to have this, but I think it’s beyond the
scope of the ‘timer’ feature.  :-)

Ludo’.

Problem building rust application

[Andreas Enge]

Hello,

I am interested in some software written in rust, and have used
"guix import -r" to reach the attached file. Compilation of kanata fails
with the following message:

starting phase `build'
error: failed to select a version for `core-graphics-types`.
... required by package `core-graphics v0.23.2`
... which satisfies dependency `core-graphics = "^0.23.2"` of package 
`kanata v1.7.0-prerelease-2 
(/tmp/guix-build-kanata-1.7.0-prerelease-2.drv-0/kanata-1.7.0-prerelease-2)`
versions that meet the requirements `^0.1` are: 0.1.1

the package `core-graphics` depends on `core-graphics-types`, with features: 
`link` but `core-graphics-types` does not have these features.

failed to select a version for `core-graphics-types` which could resolve this 
conflict

We do have core-graphics-types@0.23.2 and core-graphics-types@0.1.1, so the
versions look okay to my untrained eye.

The problem seems to lie rather in the mysterious "link" feature.
Could some rust expert explain the problem to me, and give a hint
as to what I could do?

Thanks a lot,

Andreas

;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2024 Andreas Enge 
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see .

(define-module (gnu packages kanata)
   #:use-module (guix build-system cargo)
   #:use-module (guix download)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (gnu packages)
   #:use-module (gnu packages crates-apple)
   #:use-module (gnu packages crates-graphics)
   #:use-module (gnu packages crates-io)
   #:use-module (gnu packages crates-windows)
)

(define-public rust-time-macros-0.2
  (package
(name "rust-time-macros")
(version "0.2.18")
(source
 (origin
   (method url-fetch)
   (uri (crate-uri "time-macros" version))
   (file-name (string-append name "-" version ".tar.gz"))
   (sha256
(base32 "1kqwxvfh2jkpg38fy673d6danh1bhcmmbsmffww3mphgail2l99z"
(build-system cargo-build-system)
(arguments
 `(#:skip-build? #t
   #:cargo-inputs (("rust-num-conv" ,rust-num-conv-0.1)
   ("rust-time-core" ,rust-time-core-0.1
(home-page "https://github.com/time-rs/time";)
(synopsis
 "Procedural macros for the time crate.
This crate is an implementation detail and should not be relied upon 
directly.")
(description
 "This package provides Procedural macros for the time crate.  This crate 
is an implementation detail
and should not be relied upon directly.")
(license (list license:expat license:asl2.0

(define-public rust-time-0.3
  (package
(name "rust-time")
(version "0.3.36")
(source
 (origin
   (method url-fetch)
   (uri (crate-uri "time" version))
   (file-name (string-append name "-" version ".tar.gz"))
   (sha256
(base32 "11g8hdpahgrf1wwl2rpsg5nxq3aj7ri6xr672v4qcij6cgjqizax"
(build-system cargo-build-system)
(arguments
 `(#:skip-build? #t
   #:cargo-inputs (("rust-deranged" ,rust-deranged-0.3)
   ("rust-itoa" ,rust-itoa-1)
   ("rust-js-sys" ,rust-js-sys-0.3)
   ("rust-libc" ,rust-libc-0.2)
   ("rust-num-conv" ,rust-num-conv-0.1)
   ("rust-num-threads" ,rust-num-threads-0.1)
   ("rust-powerfmt" ,rust-powerfmt-0.2)
   ("rust-quickcheck" ,rust-quickcheck-1)
   ("rust-rand" ,rust-rand-0.8)
   ("rust-serde" ,rust-serde-1)
   ("rust-time-core" ,rust-time-core-0.1)
   ("rust-time-macros" ,rust-time-macros-0.2
(home-page "https://time-rs.github.io";)
(synopsis
 "Date and time library. Fully interoperable with the standard library. 
Mostly compatible with #![no_std]")
(description
 "This package provides Date and time library.  Fully interoperable with 
the standard library.  Mostly
compatible with #![no_std].")
(license (list license:expat license:asl2.0

(define-public rust-stretch-0.3
  (package
(name "rust-stretch")
(version "0.3.2")
(source
 (origin
   (method url-fetch)
   (uri (crate-uri "stretch" version))
   (file-name (string-append name "-" version ".tar.gz"))
   (sha256
(base32 "11vdml

Re: [RFC] [Feature] In project `configuration.scm` allow dependencies to other repos with `configuration.scm`

[Josh Marshall]

This is a technical workaround, not direct support.  If such a feature
is to be aimed at general developers and researchers, it can't be so
circuitous. The Invocation from any form of Guix installation needs to
be `guix shell` and just work.
https://guix.gnu.org/manual/en/guix.html#package_002ddevelopment_002dmanifest
 Would need to be extended to take a URI and git reference for
individual dependencies.

On Tue, Nov 19, 2024 at 5:28 AM Efraim Flashner  wrote:
>
> On Mon, Nov 18, 2024 at 01:25:22PM -0500, Josh Marshall wrote:
> > Hello all,
> >
> > I have come across a use case that I don't find well addressed.  If I
> > am not wrong (and I very well might be) it would be a feature which
> > could be of great use.  First sent to a Nix channel, but I think the
> > same applies here.
> >
> > ```
> > I want to use git repos with Nix Flakes in them directly as if they
> > were package dependencies in another Flake. I can't seem to find good
> > documentation for this. Is it even a thing? The purpose is to improve,
> > but not impose perfection or slowdown, on developers or researchers as
> > they Nix-ify their projects. The application is that I have a root
> > project that needs to be put into a flake, which in turn has a number
> > of other projects which are not Nix packages but could feasibly add a
> > Nix Flake. The end goal is to be able to set up and package a project
> > such that the end result is as easy to replicate for others as
> > described here:
> > https://obscuratur-in-arena.readthedocs.io/en/latest/A-good-way-to-set-up-your-python-project-using-Nix-Direnv-and-Poetry.html
> > ```
> >
> > I regret that I must again be someone who just throws more work
> > demands into the ether.  The whole "I am finite" thing.
>
> There are a number of projects (like shepherd) which are also setup to
> function as a channel. And Guix has the ability for channels to depend
> on other channels. So it would be possible to create a package in a
> channel which depended on a specific branch (or commit) of shepherd as
> it appeared upstream.  Is that the type of thing you mean?
>
>
> --
> Efraim Flashner  אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted