bug#57467: 'guix shell' does not honor default behavior when given a specific command to run

[Ludovic Courtès]

Hi David,

Thanks for your feedback on this.

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

> So there are some competing expectations here. The status quo is that
> non-interactive invocations of 'guix shell' will not load a guix.scm or
> manifest.scm file unless explicitly told to via --file/--manifest following
> the "explicit is better than implicit" philosophy.  People like myself who
> almost exclusively invoke 'guix shell' without any arguments would expect
> that 'guix shell -- make' would load their guix.scm file like they're used
> to.  It is the latter expectation that is typically the status quo in other
> language environments.  For example, in Ruby land, 'bundle exec foo' runs
> the command 'foo' non-interactively in the context of a project and you
> don't have to tell it where to find the conventional Gemfile because it's
> the default.  Treating interactive and non-interactive invocation
> differently in 'guix shell' was a surprise for me.  Of course, 'guix shell
> -D -f guix.scm -- make' works, but it doesn't "just work."

Right.  As you note, there were different expectations and constraints
when we discussed this.  We ended up with a tradeoff that has its pros
and cons.  The whole discussion took place here:

  https://issues.guix.gnu.org/50960

As a side note, I think as a project we may want to set up an RFC kind
of process to have a documented way to make decisions like these.  This
would ensure every person who wants to chime in has an opportunity to do
so, even people who would not follow implementation discussions or
follow the patch stream on guix-patches.  Food for thought!

> Both viewpoints have their merits and I'm wondering if there's a way
> to satisfy both expectations.  Perhaps 'guix shell -- make' would load
> guix.scm, but 'guix shell --pure -- make', or any invocation with any
> flags, would not?  Or, less ideal, a new short flag that can be passed
> that would be the equivalent of `-D -f guix.scm` (or the manifest.scm
> variant) to at least make for less typing.  Personally, I think that
> defaulting to loading from a conventional file when no packages are
> specified is much more user friendly than generating an empty profile,
> regardless of interactive vs.  non-interactive.

The main reason to me for distinguishing non-interactive behavior is
ensuring that scripts behave in a deterministic fashion, as opposed to
having their behavior dependent on the presence of a file in $PWD.

FWIW, I’m rather satisfied with the current behavior, though I’m open to
other opinions (and indeed, feedback from users of other tools in this
area is much welcome).

The main difficulty here is that, should we eventually decide to change
behaviors, we’ll have to devise a migration timeline etc.  (As an
example, we chose to keep ‘guix environment’ until at least May 2023;
all this must take time if we want to avoid breaking user workflows.)

Thoughts?

Thanks,
Ludo’.