Issue with 'guix shell' for Guile projects on non-Guix distros

Issue with 'guix shell' for Guile projects on non-Guix distros

[Thompson, David]

Hey everyone,

At Spritely we've run into a situation where 'guix shell' doesn't
"just work" for setting up a development environment and we're
wondering about the best way to fix it.  We're experiencing this issue
with our guile-goblins project currently, but this appears to be a
more general problem that likely affects most projects that use
Guile's guile.m4 autoconf code.

Here's the context: Someone wants to build guile-goblins from a Git
checkout using their non-Guix, FHS distro. However, they happen to
have Guile 3 installed to /usr via the host distro's package manager.
They install Guix, run 'guix shell', then './bootstrap.sh' and that
all works fine. Then they run './configure' and this happens:

    $ ./configure
    checking for a BSD-compatible install...
/gnu/store/w7ag4ilvb6inp9vc71dxzmdkz738m37w-profile/bin/install -c
    checking whether build environment is sane... yes
    checking for a thread-safe mkdir -p...
/gnu/store/w7ag4ilvb6inp9vc71dxzmdkz738m37w-profile/bin/mkdir -p
    checking for gawk... gawk
    checking whether make sets $(MAKE)... yes
    checking whether make supports nested variables... yes
    checking whether make supports nested variables... (cached) yes
    checking for pkg-config...
/gnu/store/w7ag4ilvb6inp9vc71dxzmdkz738m37w-profile/bin/pkg-config
    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.7
    checking for guild-3.0...
/gnu/store/w7ag4ilvb6inp9vc71dxzmdkz738m37w-profile/bin/guild
    checking for guile-config-3.0... no
    checking for Guile site directory...
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/share/guile/site/3.0
    checking for Guile site-ccache directory using pkgconfig...
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/lib/guile/3.0/site-ccache
    checking for Guile extensions directory...
/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/lib/guile/3.0/extensions
    checking if (fibers) is available... no
    configure: error: required guile module not found: (fibers)

The most important line above is:

    checking for guile-3.0... /usr/bin/guile-3.0

Guile's guile.m4 code checks for a 'guile-3.0' executable *before*
checking for a 'guile' executable.  Guix's Guile package only provides
'guile', but the host distro provides 'guile-3.0'.  Unfortunately, the
build environment ends up as a mix of host distro and Guix things
which eventually proves fatal to the build.

As a workaround, I am considering adding a package to our manifest.scm
file that symlinks 'guile' to 'guile-3.0', 'guild' to 'guild-3.0',
etc. so that they take priority over the host executables.
Internally, we are tracking this issue here:
https://gitlab.com/spritely/guile-goblins/-/issues/84

Has anyone encountered something like this before?  If so, how did you
deal with it?  Should something be changed in Guix itself to avoid
this issue altogether?

- Dave

Re: Issue with 'guix shell' for Guile projects on non-Guix distros

[Ludovic Courtès]

Hello,

"Thompson, David" <dthompson2@worcester.edu> skribis:

> Here's the context: Someone wants to build guile-goblins from a Git
> checkout using their non-Guix, FHS distro. However, they happen to
> have Guile 3 installed to /usr via the host distro's package manager.

I was going to suggest running ‘guix shell --check …’, which can detect
a class of problems on non-Guix distros, but that’s not the problem
here.

> They install Guix, run 'guix shell', then './bootstrap.sh' and that
> all works fine. Then they run './configure' and this happens:

[...]

> The most important line above is:
>
>     checking for guile-3.0... /usr/bin/guile-3.0
>
> Guile's guile.m4 code checks for a 'guile-3.0' executable *before*
> checking for a 'guile' executable.  Guix's Guile package only provides
> 'guile', but the host distro provides 'guile-3.0'.  Unfortunately, the
> build environment ends up as a mix of host distro and Guix things
> which eventually proves fatal to the build.

I’ve not encountered this before.

My suggestion would be to recommend running ‘guix shell -CP’ as this
addresses problems of that sort once and for all.  I do that, even on
Guix System: it’s pretty reassuring to know that your dev environment is
isolated from the rest.

Alternatively, ‘guix shell --pure’ would also address that because then
‘configure’ wouldn’t look for programs under /usr/bin.  It’s less robust
though.

HTH,
Ludo’.

Re: Issue with 'guix shell' for Guile projects on non-Guix distros

[Thompson, David]

Hi Ludo,

On Thu, Mar 16, 2023 at 11:55 AM Ludovic Courtès <ludo@gnu.org> wrote:
>
> Hello,
>
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
> > Here's the context: Someone wants to build guile-goblins from a Git
> > checkout using their non-Guix, FHS distro. However, they happen to
> > have Guile 3 installed to /usr via the host distro's package manager.
>
> I was going to suggest running ‘guix shell --check …’, which can detect
> a class of problems on non-Guix distros, but that’s not the problem
> here.
>
> > They install Guix, run 'guix shell', then './bootstrap.sh' and that
> > all works fine. Then they run './configure' and this happens:
>
> [...]
>
> > The most important line above is:
> >
> >     checking for guile-3.0... /usr/bin/guile-3.0
> >
> > Guile's guile.m4 code checks for a 'guile-3.0' executable *before*
> > checking for a 'guile' executable.  Guix's Guile package only provides
> > 'guile', but the host distro provides 'guile-3.0'.  Unfortunately, the
> > build environment ends up as a mix of host distro and Guix things
> > which eventually proves fatal to the build.
>
> I’ve not encountered this before.
>
> My suggestion would be to recommend running ‘guix shell -CP’ as this
> addresses problems of that sort once and for all.  I do that, even on
> Guix System: it’s pretty reassuring to know that your dev environment is
> isolated from the rest.
>
> Alternatively, ‘guix shell --pure’ would also address that because then
> ‘configure’ wouldn’t look for programs under /usr/bin.  It’s less robust
> though.

I should have mentioned that we did get a working environment by using
--container, but it required explaining why the tools from the host,
like git, were no longer available and how those would have to be used
outside of the Guix shell.  Same with --pure, only with additional
complications because of a .bashrc that was referring to lesspipe and
other things that were no longer available.  I tend to prefer plain
'guix shell' because, usually, it does the right thing without
additional surprises for someone who is unfamiliar with Guix.  Each
method has its downsides, not sure what to recommend going forward.

- Dave