From: "Thompson, David" <dthompson2@worcester.edu>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: help-guix <help-guix@gnu.org>
Subject: Re: Issue with 'guix shell' for Guile projects on non-Guix distros
Date: Thu, 16 Mar 2023 12:21:46 -0400 [thread overview]
Message-ID: <CAJ=RwfZpnHZz5Ec+_59EYVw+xmiAdaTnYc9=BNM+g_D945whVg@mail.gmail.com> (raw)
In-Reply-To: <87cz58d733.fsf@gnu.org>
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
prev parent reply other threads:[~2023-03-16 16:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-16 14:15 Issue with 'guix shell' for Guile projects on non-Guix distros Thompson, David
2023-03-16 15:55 ` Ludovic Courtès
2023-03-16 16:21 ` Thompson, David [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ=RwfZpnHZz5Ec+_59EYVw+xmiAdaTnYc9=BNM+g_D945whVg@mail.gmail.com' \
--to=dthompson2@worcester.edu \
--cc=help-guix@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.