bug#64509: Guile packages should install versioned aliases for binaries (guile-X.Y, guild-X.Y, etc.)

bug#64509: Guile packages should install versioned aliases for binaries (guile-X.Y, guild-X.Y, etc.)

[Zack Weinberg]

The Guile packages currently install all their binaries under their
basic name only, e.g.

$ ls /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin
/gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin:
guild  guile  guile-config  guile-snarf  guile-tools

However, the Autoconf macro GUILE_PROGS (from guile.m4) looks first
for a guile binary with a version number suffix (e.g. ‘guile-3.0’).
If it finds one, then it looks *only* for a matching guild-X.Y and
errors out if it can’t find that.  This is a problem for building Guix
itself from source in a non-pure ‘guix shell -D guix’ on top of a
foreign distro that provides a ‘guile-3.0’ binary but not the other
four programs:

$ which guile || echo not found
/gnu/store/1yg0gg12m2cj2lj08r3qx8yx6zir4a38-profile/bin/guile

$ which guile-3.0 || echo not found
/usr/bin/guile-3.0

$ which guild || echo not found
/gnu/store/1yg0gg12m2cj2lj08r3qx8yx6zir4a38-profile/bin/guild

$ which guild-3.0 || echo not found
not found

$ ./configure --localstatedir=/var
...
checking pkg-config is at least version 0.9.0... yes
configure: checking for guile 3.0
configure: found guile 3.0
checking for guile-3.0... /usr/bin/guile-3.0
checking for Guile version >= 3.0... 3.0.8
checking for guild-3.0... no
checking for guile-config-3.0... no
checking for guile-tools-3.0... no
configure: error: 'guild' binary not found; please check your Guile installation.

Thus, I suggest that all of the Guix guile packages should be modified
to install ‘guile-X.Y’, ‘guild-X.Y’, etc. as well as the unsuffixed
program names.  I do not immediately see how to make this change in
gnu/packages/guile.scm.

zw

bug#64509: Guile packages should install versioned aliases for binaries (guile-X.Y, guild-X.Y, etc.)

[Ludovic Courtès]

Hi Zack,

"Zack Weinberg" <zack@owlfolio.org> skribis:

> The Guile packages currently install all their binaries under their
> basic name only, e.g.
>
> $ ls /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin
> /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin:
> guild  guile  guile-config  guile-snarf  guile-tools
>
> However, the Autoconf macro GUILE_PROGS (from guile.m4) looks first
> for a guile binary with a version number suffix (e.g. ‘guile-3.0’).
> If it finds one, then it looks *only* for a matching guild-X.Y and
> errors out if it can’t find that.  This is a problem for building Guix
> itself from source in a non-pure ‘guix shell -D guix’ on top of a
> foreign distro that provides a ‘guile-3.0’ binary but not the other
> four programs:

I think the solution is to use ‘guix shell -D guix -CP’: that’ll give
you a container, where /usr/bin/guile-3.0 isn’t accessible, which
ensures there’s no interference.

(FWIW this is what I do, even on Guix System, for my development
environments.)

Does that work for you?

If your distro doesn’t support unprivileged user namespaces, which ‘-C’
relies on, you can fall back to ‘--pure’.

Ludo’.

bug#64509: Guile packages should install versioned aliases for binaries (guile-X.Y, guild-X.Y, etc.)

[Zack Weinberg]

On Tue, Aug 15, 2023, at 5:33 PM, Ludovic Courtès wrote:
>> The Guile packages currently install all their binaries under their
>> basic name only, e.g.
...
>> This is a problem for building Guix
>> itself from source in a non-pure ‘guix shell -D guix’ on top of a
>> foreign distro that provides a ‘guile-3.0’ binary but not the other
>> four programs:
>
> I think the solution is to use ‘guix shell -D guix -CP’: that’ll give
> you a container, where /usr/bin/guile-3.0 isn’t accessible, which
> ensures there’s no interference.

I can't use container mode (or pure mode), because there's another
layer in the way: I'm using <https://github.com/purcell/envrc> to
pull settings out of `guix shell` and poke them into Emacs.  This
inherently only supports non-pure operation.

zw

bug#64509: Guile packages should install versioned aliases for binaries (guile-X.Y, guild-X.Y, etc.)

[Janneke Nieuwenhuizen]

Ludovic Courtès writes:

Hello!

> "Zack Weinberg" <zack@owlfolio.org> skribis:
>
>> The Guile packages currently install all their binaries under their
>> basic name only, e.g.
>>
>> $ ls /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin
>> /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin:
>> guild  guile  guile-config  guile-snarf  guile-tools
>>
>> However, the Autoconf macro GUILE_PROGS (from guile.m4) looks first
>> for a guile binary with a version number suffix (e.g. ‘guile-3.0’).
>> If it finds one, then it looks *only* for a matching guild-X.Y and
>> errors out if it can’t find that.  This is a problem for building Guix
>> itself from source in a non-pure ‘guix shell -D guix’ on top of a
>> foreign distro that provides a ‘guile-3.0’ binary but not the other
>> four programs:

It's an interesting idea.  It's a common source of problems for non-guix
system users.  It's terrible that guile.m4 has this feature of
preferring numbered binaries (even if they're later in PATH, and even if
that binary doesn't match GUILE_LOAD_*PATHs), and that Guix doesn't
provide them.

What about a wrapper package that provides these?

> I think the solution is to use ‘guix shell -D guix -CP’: that’ll give
> you a container, where /usr/bin/guile-3.0 isn’t accessible, which
> ensures there’s no interference.
>
> (FWIW this is what I do, even on Guix System, for my development
> environments.)

Hmm, yeah -- that sounds like the proper way of doing things.  Maybe my
pracice and advise should go into that direction instead.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

bug#64509: Guile packages should install versioned aliases for binaries (guile-X.Y, guild-X.Y, etc.)

[Zack Weinberg]

On Mon, Aug 21, 2023, at 3:37 AM, Janneke Nieuwenhuizen wrote:

> It's terrible that guile.m4 has this feature of preferring numbered
> binaries (even if they're later in PATH, and even if that binary
> doesn't match GUILE_LOAD_*PATHs)

I can see why it does this -- it wants to find the newest available
Guile and it wants to be sure that all the binaries it uses are a
matched set. The original design assumption was probably that, if you're
using numbered binaries, then the un-suffixed "guile" can't be relied on
to be the newest available.  (Not as strange as it might sound; I have a
login on a machine where un-suffixed "perl" still runs Perl 5.005_02,
because the admins want to make absolutely sure that they never break
any user's #! scripts.)

It would probably be a good idea for guile.m4 to be altered to take the
un-suffixed binaries if that's the only way it can get a full set, but
given how long it takes for Autoconf macro changes to propagate to the
world, I think Guix should provide the numbered binaries regardless.

> and that Guix doesn't provide them. What about a wrapper package that
> provides these?

Why bother with a wrapper?  It should be _easier_ to have the main guile
package supply the numbered binaries.

>> I think the solution is to use ‘guix shell -D guix -CP'
...
> Hmm, yeah -- that sounds like the proper way of doing things
...

Not an option for me, for reasons explained in my earlier reply to
Ludovic.

zw