Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[Csepp]

Simon Tournier  writes:

> Hi,
>
> As bug#60200 [1], the issue is one that many of us often hit: packages
> with several versions and when the highest one is not the default.
>
> Other said, build systems use some version for compiler and tools but
> Guix can also offer more recent versions for these very same compilers
> and tools.  It leads to the issue when selecting the name of a compiler
> or tool (command line or manifest).  The user does not get the ones used
> as default by build system.
>
> In addition to [1], another example:
>
> $ guix shell ocaml ocaml-ppxlib -- ocaml --version
> The OCaml toplevel, version 5.0.0
>
>
> But the OCaml libraries are built using OCaml compiler v4.14, thus it
> leads to error as:
>
> Error: 
> /gnu/store/vglxlc8riynj1g937clvwv8yg40lln6z-profile/lib/ocaml/site-lib/ppxlib/ppxlib.cmi
>is not a compiled interface for this version of OCaml.
> It seems to be for an older version of OCaml.
>
> For other cases, such issue is avoided by appending the suffix -next to
> package name; as with ghc-next, python-numpy-next, emacs-next, etc.
>
> Personally, I find the -next trick useful because the package name
> reflects that it is not the default.  However, it can be annoying to
> update manifest files when this -next is becoming default.
>
> Well, what do people think about this Lars’s patch?

As I *just* ran into some OCaml and GCC related issues a few days ago,
I'm in favor of either the default flag or expanding the -next suffix
naming convention to more packages.

unified cgroups / rootless podman

[Csepp]

I'm trying to set up a Debian container to test some things and thought
I'd try rootless podman instead of a simple chroot which requires root
privileges.
TLDR I ran into some problems which on other distros are apparently
solved by configuring the init system.
>From the StackOverflow answer:
> From what I see, you need to set rc_cgroup_mode="unified" in the rc.conf file.
> If you were using systemd instead, you'd need to run # grubby
> --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=1".

What - if anything - is the equivalent on Guix/Shepherd?

Guix home migration

[Ryan Prior]

Migrating application settings to guix-home is something we want to make really 
approachable. Right now it's a relatively new and little-known feature but it 
could quickly become one of the top use cases for Guix, as a lot of people are 
interested in declarative application configuration.

A free software project to look at for ideas is Mackup: 
https://github.com/lra/mackup
Its strategy is unsophisticated: it moves your configuration files to a 
synchronized directory in Dropbox (or similar) and replaces it with a symlink. 
But it's got a great migration story: you run `mackup backup' and it scans for 
config files for hundreds of applications [1] and automatically migrates them.

Whether or not we would want the exact same experience, the overall vision of a 
single migration command that scans for dotfiles and adds them to your guix 
home is something we can aspire to.

[1]: https://github.com/lra/mackup/tree/master/mackup/applications

Re: bug#58813: can't substitute etc/teams.scm command as doc suggests

[Maxim Cournoyer]

Hi Simon,

Simon Tournier  writes:

> Hi,
>
> On Mon, 09 Jan 2023 at 15:52, Maxim Cournoyer  
> wrote:
>
>> It wouldn't change; patman would be hinted at briefly with a reference
>> to its documentation (info '(u-boot) Patman patch manager' from the
>> u-boot-documentation package) as a nice way to stay organize with
>> submissions and automate a few things on top of git send-email.
>
> Is it possible to read online patman documentation?  I am not able to
> find one.

It's developed as part of U-Boot and available at
https://u-boot.readthedocs.io/en/latest/develop/patman.html.  It's
generated from the same sources as the info manual from
u-boot-documentation referenced above.

> Moreover, it could ease the adoption if a minimal sample of
> such configuration is provided.  A minimal out of the box configuration
> as starter.

No configuration is required other than the .patman file already checked
in Guix.

> On my side, if I have to do more than just click to read documentation,
> then I give up.  And then, if I have to parse lengthy documentation,
> then it depends on my motivation but it is also possible that I give
> up–the well-known RTFM trap.  In other words, I am lazy. :-)

The 'Patman patch manager' section is relatively compact; I read it from
the comfort of Emacs ;-).  There's also some alternative short text
available as 'patman -H' if you are in a hurry.

-- 
Thanks,
Maxim

Re: Golang go-updates feature branch?

[Leo Famulari]

On Wed, Jan 11, 2023 at 10:11:09AM -0700, Katherine Cox-Buday wrote:
> I also think this is a fantastic idea, and like John, I think mesa is another 
> good candidate (and not only because I recently would have benefited from 
> this).

Yeah, mesa is *the* archetypal package for the 'staging' branch, since
its reverse dependency graph is too big to rebuild on the 'master'
branch but it's not a "core" package. If we do go down that road, we
will still need to be judicious about how often we do it. Mesa has ~4000
dependents and we don't want to boil the ocean.

Before we can continue, I / we have to debug the patches I sent a few
messages ago:

https://lists.gnu.org/archive/html/guix-devel/2023-01/msg00131.html

Paging guix-sysadmin for assistance...

Re: Ability to specify compiler package for Go build system.

[Leo Famulari]

On Wed, Jan 11, 2023 at 08:02:15PM -0500, Leo Famulari wrote:
> That's correct. You can put something like this in the package
> arguments:
> 
> #:go ,go-1.19

This was undocumented... sorry! I just rectified that in commit
9ec62d1b9c55104f9ab81b95d82988c627a23415.

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9ec62d1b9c55104f9ab81b95d82988c627a23415

Re: Ability to specify compiler package for Go build system.

[Leo Famulari]

On Wed, Jan 11, 2023 at 05:25:18PM +, ( wrote:
> Pretty sure there *is* already a #:go argument, but I might be misremembering.

That's correct. You can put something like this in the package
arguments:

#:go ,go-1.19

Re: Command consistency: suggestion

[Simon Tournier]

Hi,

On Mon, 09 Jan 2023 at 12:22, Paul Jewell via "Development of GNU Guix and the 
GNU System distribution."  wrote:

> guix package --list-generations
>
> and
>
> guix system list-generations
>
> guix package has everything as an flag, but guix system (and guix home) 
> uses the concept of ACTION with options and arguments.

Well, “guix package“ also uses action and it is possible to combine
them.  For an example about the issue it leads, see bug#50473 [1].

1: 

> Perhaps the latter is clearer, and guix package should also follow the 
> same model?

It is often discussed. :-) Well, ‘guix package’ uses SRFI-37 [2] and it
is possible to combine some action; as --switch-generation and
--delete-generations for instance.  Aside note that one transaction can
install and remove:

guix package -i foo -r bar

which would not be possible when using single action.

The CLI of ‘guix package’ will not change, IMHO.  The mitigation of what
you are considering as an inconsistency is to have “alias“; guix search,
guix, install, guix remove, etc.

Last, we could imagine a Guix extension [3] and then (not checked :-))
maybe the user could opt in and install this extension for replacement.

2: 
3: 

Cheers,
simon

Re: [PATCH guix-artwork v4] website: posts: Add Dissecting Guix, Part 1: Derivations.

[zimoun]

Hi,

On Tue, 10 Jan 2023 at 06:59, "("  wrote:

> Probably, yeah.  It might take me longer to write the monads post, since i 
> didn't
> understand Guix's monads when I started :) (I do understand them a bit now, 
> though.)

Feel free to post to guix-b...@gnu.org even an early draft if you want
some early feedback.  Well, if this private alias is still working. :-)

(Hum, I do not remember who is behind in addition to me. ;-)))

Cheers,
simon

Re: Ability to specify compiler package for Go build system.

[Ekaitz Zarraga]

> Pretty sure there is already a #:go argument, but I might be misremembering.


Just took a look in the build-system and I can't find that argument.
Maybe I didn't search correctly anyway... :)

Cheers!

properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[Simon Tournier]

Hi,

As bug#60200 [1], the issue is one that many of us often hit: packages
with several versions and when the highest one is not the default.

Other said, build systems use some version for compiler and tools but
Guix can also offer more recent versions for these very same compilers
and tools.  It leads to the issue when selecting the name of a compiler
or tool (command line or manifest).  The user does not get the ones used
as default by build system.

In addition to [1], another example:

--8<---cut here---start->8---
$ guix shell ocaml ocaml-ppxlib -- ocaml --version
The OCaml toplevel, version 5.0.0
--8<---cut here---end--->8---

But the OCaml libraries are built using OCaml compiler v4.14, thus it
leads to error as:

--8<---cut here---start->8---
Error: 
/gnu/store/vglxlc8riynj1g937clvwv8yg40lln6z-profile/lib/ocaml/site-lib/ppxlib/ppxlib.cmi
   is not a compiled interface for this version of OCaml.
It seems to be for an older version of OCaml.
--8<---cut here---end--->8---

For other cases, such issue is avoided by appending the suffix -next to
package name; as with ghc-next, python-numpy-next, emacs-next, etc.

Personally, I find the -next trick useful because the package name
reflects that it is not the default.  However, it can be annoying to
update manifest files when this -next is becoming default.

Well, what do people think about this Lars’s patch?

diff --git a/gnu/packages.scm b/gnu/packages.scm
index 61345f75a9..7e5a6d49c2 100644
--- a/gnu/packages.scm
+++ b/gnu/packages.scm
@@ -356,20 +356,24 @@ (define cache
(find-packages-by-name/direct name version
 
 (define (find-best-packages-by-name name version)
-  "If version is #f, return the list of packages named NAME with the highest
-version numbers; otherwise, return the list of packages named NAME and at
-VERSION."
+  "If version is #f, return the list of packages named NAME with only
+packages marked default? or, if none exist, the highest version numbers;
+otherwise, return the list of packages named NAME and at VERSION."
   (if version
   (find-packages-by-name name version)
   (match (find-packages-by-name name)
 (()
  '())
 ((matches ...)
- ;; Return the subset of MATCHES with the higher version number.
- (let ((highest (package-version (first matches
-   (take-while (lambda (p)
- (string=? (package-version p) highest))
-   matches))
+ ;; Return the subset of MATCHES which are marked default or those with
+ ;; the higher version number.
+ (let ((highest (package-version (first matches)))
+   (default (filter (lambda (p) (assoc-ref (package-properties p) 'default?)) matches)))
+   (if (not (null? default))
+   default
+   (take-while (lambda (p)
+ (string=? (package-version p) highest))
+   matches)))
 
 ;; Prevent Guile 3 from inlining this procedure so we can mock it in tests.
 (set! find-best-packages-by-name find-best-packages-by-name)
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index b4566b41cc..2d5e0add26 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -3855,7 +3855,10 @@ (define* (make-gcc-toolchain gcc
 ("libc-static" ,libc "static"))
 
 (define-public gcc-toolchain
-  (make-gcc-toolchain gcc-final))
+  (let ((parent (make-gcc-toolchain gcc-final)))
+(package
+  (inherit parent)
+  (properties (alist-cons 'default? #t (package-properties parent))
 
 (define-public gcc-toolchain-4.8
   (make-gcc-toolchain gcc-4.8))


1: 

Cheers,
simon

Re: Time for ocaml-xzy.scm and reorganizing OCaml packages?

[Julien Lepiller]

Le Wed, 11 Jan 2023 20:05:58 +0100,
Simon Tournier  a écrit :

> Hi,
> 
> Maybe it is time for ocaml-xzy.scm. :-)
> 
> Currently, the file gnu/packages/ocaml.scm contains 315 define-public.
> Maybe, it would make sense to have:
> 
>  + ocaml.scm for compiler and essentials (as ocaml-findlib or dune)
>  + ocaml-xyz.scm for ocaml- packages
>  + ocaml-apps.scm for standalone program written in OCaml as unison,
>ocamlmod, etc
>  + ocaml-legacy.scm for the old ocaml4.0x things
> 
> WDYT?

Sounds good to me. Are you planning to work on a patch?

> 
> Well, with the question of the new ocaml5 thing. :-)
> 
> Trying to package some OCaml, I note that the OCaml package named
> camlzip is not prefixed with ’ocaml-’ although it can only be used as
> a library, IIUC.
> 
> --8<---cut here---start->8---
> $ tree $(guix build camlzip)
> /gnu/store/r7p7azlfwrjs5c6kbwb50pvlqxi4k776-camlzip-1.11
> ├── bin
> ├── lib
> │   └── ocaml
> │   └── site-lib
> │   ├── camlzip
> │   │   └── META
> │   └── zip
> │   ├── dllcamlzip.so
> │   ├── gzip.cmi
> │   ├── gzip.cmt
> │   ├── gzip.cmti
> │   ├── gzip.cmx
> │   ├── gzip.mli
> │   ├── libcamlzip.a
> │   ├── META
> │   ├── zip.a
> │   ├── zip.cma
> │   ├── zip.cmi
> │   ├── zip.cmt
> │   ├── zip.cmti
> │   ├── zip.cmx
> │   ├── zip.cmxa
> │   ├── zip.cmxs
> │   ├── zip.mli
> │   ├── zlib.cmi
> │   ├── zlib.cmt
> │   ├── zlib.cmti
> │   ├── zlib.cmx
> │   └── zlib.mli
> └── share
> └── doc
> └── camlzip-1.11
> └── LICENSE
> 
> 9 directories, 24 files
> --8<---cut here---end--->8---
> 
> Moreover, “guix import opam -r camlzip” returns,
> 
> (define-public ocaml-camlzip
>   (package
> (name "ocaml-camlzip")
> 
> Well, therefore I would be expecting ocaml-camlzip to be consistent
> with the Guix naming convention.  And with this large
> gnu/packages/ocaml.scm file containing all the OCaml related stuff, I
> am guessing that it’s time to reorganize a bit.  WDYT?

We can rename camlzip :)

> 
> Cheers,
> simon

Time for ocaml-xzy.scm and reorganizing OCaml packages?

[Simon Tournier]

Hi,

Maybe it is time for ocaml-xzy.scm. :-)

Currently, the file gnu/packages/ocaml.scm contains 315 define-public.
Maybe, it would make sense to have:

 + ocaml.scm for compiler and essentials (as ocaml-findlib or dune)
 + ocaml-xyz.scm for ocaml- packages
 + ocaml-apps.scm for standalone program written in OCaml as unison,
   ocamlmod, etc
 + ocaml-legacy.scm for the old ocaml4.0x things

WDYT?

Well, with the question of the new ocaml5 thing. :-)

Trying to package some OCaml, I note that the OCaml package named
camlzip is not prefixed with ’ocaml-’ although it can only be used as a
library, IIUC.

--8<---cut here---start->8---
$ tree $(guix build camlzip)
/gnu/store/r7p7azlfwrjs5c6kbwb50pvlqxi4k776-camlzip-1.11
├── bin
├── lib
│   └── ocaml
│   └── site-lib
│   ├── camlzip
│   │   └── META
│   └── zip
│   ├── dllcamlzip.so
│   ├── gzip.cmi
│   ├── gzip.cmt
│   ├── gzip.cmti
│   ├── gzip.cmx
│   ├── gzip.mli
│   ├── libcamlzip.a
│   ├── META
│   ├── zip.a
│   ├── zip.cma
│   ├── zip.cmi
│   ├── zip.cmt
│   ├── zip.cmti
│   ├── zip.cmx
│   ├── zip.cmxa
│   ├── zip.cmxs
│   ├── zip.mli
│   ├── zlib.cmi
│   ├── zlib.cmt
│   ├── zlib.cmti
│   ├── zlib.cmx
│   └── zlib.mli
└── share
└── doc
└── camlzip-1.11
└── LICENSE

9 directories, 24 files
--8<---cut here---end--->8---

Moreover, “guix import opam -r camlzip” returns,

(define-public ocaml-camlzip
  (package
(name "ocaml-camlzip")

Well, therefore I would be expecting ocaml-camlzip to be consistent with
the Guix naming convention.  And with this large gnu/packages/ocaml.scm
file containing all the OCaml related stuff, I am guessing that it’s
time to reorganize a bit.  WDYT?

Cheers,
simon
Message-ID: <867cxs51um@gmail.com>

Re: Ability to specify compiler package for Go build system.

[(]

On Wed Jan 11, 2023 at 1:49 AM GMT, Hilton Chain wrote:
> Though it's possible to package the last version supports Go 1.17 (v1.38.0), 
> I wonder if we can
> adjust the build system so that a Go package could be specified via an 
> argument in the package
> definition.

Pretty sure there *is* already a #:go argument, but I might be misremembering.

-- (


signature.asc
Description: PGP signature

Re: Ability to specify compiler package for Go build system.

[Katherine Cox-Buday]

Hilton Chain  writes:

> Hi Guix,
>
> I'm trying to package wakatime-cli[1], while Guix uses Go 1.17 as the
> default, the package requires Go 1.19 at the current version
> (v1.60.4).
>
> Though it's possible to package the last version supports Go 1.17
> (v1.38.0), I wonder if we can adjust the build system so that a Go
> package could be specified via an argument in the package definition.

As a temporary work-around, you can do this in a channel:

https://github.com/kat-co/guix-channels/blob/5c17bdd6c4ae801effdf1069df69ec4e2ce0a0dd/upstream/packages/golang.scm#L58-L59

https://github.com/kat-co/guix-channels/blob/5c17bdd6c4ae801effdf1069df69ec4e2ce0a0dd/upstream/packages/golang.scm#L818

Or maybe Ekaitz's suggestion might work.

At any rate, work is underway to bring Guix's default Go up to 1.19:
https://lists.gnu.org/archive/html/guix-devel/2023-01/msg00097.html

-- 
Katherine

Re: Golang go-updates feature branch?

[Katherine Cox-Buday]

Leo Famulari  writes:

> Now that our build farm is running smoothly, I propose we revive the
> practice of feature branches, when appropriate.

It was on my TODO list to bring this up on the mailing list! Thank you, Leo!

I also think this is a fantastic idea, and like John, I think mesa is another 
good candidate (and not only because I recently would have benefited from this).

> The first one that I propose is a go-updates branch, where we update
> the Go compilers. This will affect ~500 packages.
>
> If I understand correctly, Go is a relatively self-contained reverse
> dependency graph within Guix and thus a good candidate for this
> approach. It contains the Go libaries, and then some end-user
> applications, and they don't really affect other packages. So, it
> should be easy to understand when the update is ready to push.
>
> I can set up a jobset on ci.guix.gnu.org if people like the idea.

This was also on my TODO list for this week, and I would love to
coordinate! I'm still pretty unfamiliar with the email based workflow
and managing our CI, so this could be a great mentoring opportunity!

The things I wanted to do:

* Dust off 55210 to support a `go-next` package.

There are two uses for compilers: (1) Building Guix packages (2)
Installing in profiles for use. For (2), in addition to feature
branches, it would be nice to be able to quickly release the latest Go
package without having to immediately worry about testing all of Guix.
The idea with 55210 was to try and do this. I think this is the first
thing we should do, and we should land Go 1.19 as the first `go-next`.

We should also try and 

* Bring the default Go in Guix up to Go 1.9

* Update/create some packages

I have these in my channel I use for staging upstream changes. You can
see them from this line down:

https://github.com/kat-co/guix-channels/blob/5c17bdd6c4ae801effdf1069df69ec4e2ce0a0dd/upstream/packages/golang.scm#L429

- go-golang-org-x-vuln
- go-mvdan-cc-unparam
- go-github-com-google-go-cmdtest
- go-github-com-client9-misspell
- go-mvdan-cc-xurls-v2
- go-mvdan-cc-gofumpt
- go-github-com-google-go-cmp-cmp
- go-github-com-jba-templatecheck
- go-github-com-google-safehtml
- go-github-com-jba-printsrc
- go-golang-org-x-exp
- go-golang-org-x-mod
- go-golang-org-x-sync

There are more packages there I need to upstream, but my goal was to get
the following bullet-points into master:

* Create a package for `gopls` (Go's Language Server Protocol daemon)

I've already done the work here:

https://github.com/kat-co/guix-channels/blob/5c17bdd6c4ae801effdf1069df69ec4e2ce0a0dd/upstream/packages/golang.scm#L817-L860

* Create a home service for running gopls

I've already done the work here:

https://github.com/kat-co/guix-channels/blob/upstream-staging/upstream/home/services/gopls.scm

Go 1.20 is supposed to be released in February, so we'd have a chance to 
exercise our new Go feature-branch for 1.19 and then quickly 1.20.

I'll reach out on IRC to coordinate!

-- 
Katherine

Re: git-fetch without a hash

[Simon Tournier]

Hi,

On Mon, 09 Jan 2023 at 12:16, Ludovic Courtès  wrote:
> Simon Tournier  skribis:
>
>> Maybe my question is naive but what is the use case for this (sha256 #f)
>> in the first place?  Because maybe it could just error using some
>> ’sanitize’ for the hash record field.
>
> There’s a couple of uses: Chromium, IceCat, and Linux-libre (IIRC).
>
> I don’t like that, but I’m not sure what it would take to change these
> to  or something like that.

Well, from (gnu packages linux)

--8<---cut here---start->8---
 (origin
   (method computed-origin-method)
   (file-name (string-append "linux-libre-" version "-guix.tar.xz"))
   (sha256 #f)
--8<---cut here---end--->8---

and from (gnu packages gnuzilla)

--8<---cut here---start->8---
(origin
  (method computed-origin-method)
  (file-name (string-append "icecat-" %icecat-version ".tar.xz"))
  (sha256 #f)
--8<---cut here---end--->8---

but not from Chromium, if I read correctly.

>From my understanding, we could have something like,

  (sha256 (no-hash))

where ’no-hash’ would return a string, say
"" or whatever else
that would satisfy this hypothetical  ’sha256’ sanitizer.


Cheers,
simon

Re: bug#58813: can't substitute etc/teams.scm command as doc suggests

[Simon Tournier]

Hi,

On Mon, 09 Jan 2023 at 15:52, Maxim Cournoyer  wrote:

> It wouldn't change; patman would be hinted at briefly with a reference
> to its documentation (info '(u-boot) Patman patch manager' from the
> u-boot-documentation package) as a nice way to stay organize with
> submissions and automate a few things on top of git send-email.

Is it possible to read online patman documentation?  I am not able to
find one.  Moreover, it could ease the adoption if a minimal sample of
such configuration is provided.  A minimal out of the box configuration
as starter.

On my side, if I have to do more than just click to read documentation,
then I give up.  And then, if I have to parse lengthy documentation,
then it depends on my motivation but it is also possible that I give
up–the well-known RTFM trap.  In other words, I am lazy. :-)

Cheers,
simon

Re: Improving how NGINX modules are used and built

[Bruno Victal]

On 2023-01-09 10:51, Ludovic Courtès wrote:
> Hello!
> 
> mirai  skribis:
> 
>> An oddity of how nginx modules are packaged in guix is that they all place
>> the .so file under /etc/nginx/modules which is an odd directory to place 
>> library object files.
> 
> To me that should be treated as a bug.  Those .so files should go to
> $PKG/lib/nginx instead, or something similar.

Fixing this bug is likely to cause pain to existing module users, as the path 
to these .so
files is explicitly passed to  and is what's documented in 
the Guix manual.
<... continued below ...>

>> Looking at how network-manager-configuration handles its vpn-plugins field, 
>> it seems doable
>> that a similar approach can be used here.
>> The existing nginx-modules should be changed to install their .so files 
>> under lib{64}/nginx
>> instead and they should drop a etc/nginx/modules/foo_module.conf file 
>> responsible for loading
>> the module from the .so file. Including modules through a .conf should be 
>> preferred as
>> there's no guarantee that a module is a .so file or that it is always a
>> _single_ .so file but in general this file should typically be a one-line 
>> .conf file containing:
>>
>> load_module 
>> "/gnu/store/..nginx-foo-module/usr/lib64/nginx/ngx_foo_module.so";
>>
>>
>> And nginx-configuration should serialize the modules field as a series of 
>> lines including
>> the module .conf files, that is:
>>
>> include 
>> "/gnu/store/..nginx-foo-module/etc/nginx/modules/ngx_foo_module.conf";
>> include 
>> "/gnu/store/..nginx-bar-module/etc/nginx/modules/ngx_bar_module.conf";
>> ...
>>
>> (note: a directory union could be used here as an alternative)
> 
> I’d say that ideally, one could extend  with
> modules, and that would automatically create the ‘load_module’
> statements.

A change here would really improve how modules are used (the current way of 
things in Guix is:
for beginners: "guess the module path", for the seasoned: "build and list the 
package output
directory").

Inevitably, this won't be a backward compatible change unless we yet add another
deprecation warning and a new field "temporarily" (read as: permanently). 
(or maybe using match to differentiate between strings and file-like objects?)

I'm not convinced that  should be generating load_module 
statements here,
these should be generated by the module-package itself into a .conf file and 

generates a include statement for it. Reason being that nothing stops a module 
being comprised
of several .so files or be a "pseudo-module", that is, it's a .conf snippet to 
be included.

I haven't encountered modules like these yet but there's nothing saying that 
they can't be done this way.


Cheers,
Bruno

Re: Ability to specify compiler package for Go build system.

[Ekaitz Zarraga]

Hi,

> Hi Guix,
>
> I'm trying to package wakatime-cli[1], while Guix uses Go 1.17 as the 
> default, the package requires
> Go 1.19 at the current version (v1.60.4).
>
> Though it's possible to package the last version supports Go 1.17 (v1.38.0), 
> I wonder if we can
> adjust the build system so that a Go package could be specified via an 
> argument in the package
> definition.
>
> Thanks!
>
> [1] https://github.com/wakatime/wakatime-cli


I don't know if that's the case for the Go build system but in the gnu build 
system adding the compiler you want as an input is enough for the build system 
to use it.

Did you try that?

Cheers,
Ekaitz