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

[Thompson, David]

Hi Ludo,

On Mon, Sep 5, 2022 at 9:06 AM Ludovic Courtès <ludo@gnu.org> wrote:
>
> 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!

Yeah, that could be a good future improvement.  For what it's worth,
though, I do think you gave plenty of opportunity for commenting when
you posted that patch set.  It was just bad timing for me and I wasn't
able to participate in the discussion much.  It's all good, I think
'guix shell' is a worthy successor to 'guix environment' as it has
better UX and performance.  After all, it implements what I wanted
from 'guix environment' all those years ago where the --ad-hoc
behavior is the default.

> > 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.)

It seems that I'm all alone in wanting this and it would be far too
annoying to go through a deprecation process for a change this small,
anyway.  I'm going to close this bug.  Thanks for the additional
context.

- Dave