Re: guix shell without arguments

["Thompson, David" <dthompson2@worcester.edu>]

Hi Andre,

On Fri, May 12, 2023 at 7:07 AM André A. Gomes <andremegafone@gmail.com> wrote:
>
> Hello Guix,
>
> Issuing guix shell without arguments is equivalent to the command below,
> when guix.scm exists in the directory where it's being issued:
>
> --8<---------------cut here---------------start------------->8---
> guix shell -D -f /path/to/guix.scm
> --8<---------------cut here---------------end--------------->8---
>
> I am wondering if there's a more succinct way of saying:
>
> --8<---------------cut here---------------start------------->8---
> guix shell -D -f /path/to/guix.scm -- foo-command
> --8<---------------cut here---------------end--------------->8---
>
> The incantation below creates an empty environment.  But wouldn't it be
> nice if it would infer manifest.scm or guix.scm, in case they exist in
> the current directory?
>
> --8<---------------cut here---------------start------------->8---
> guix shell -- foo-command
> --8<---------------cut here---------------end--------------->8---

I agree with you! It's a big usability issue! Even though I'm aware of
this behavior, I still catch myself trying to do `guix shell --
foo-command` from time to time and being disappointed. I filed an
issue about this awhile back and the tl;dr is that the behavior can't
be changed (at least not easily) without breaking things for users who
have different expectations/needs: https://issues.guix.gnu.org/57467

There seem to be two main use cases that are sort of at odds with each other:

1) Users who invoke 'guix shell' in their terminal and want "do what I
mean" implicit behavior (I'm in this group and suspect you are, too)
2) Users who invoke 'guix shell' in scripts and want all behavior to
be explicit using flags so that the scripts behave in a reliable way

'guix shell' is primarily focused on case 2, and case 1 is only
supported when 'guix shell' has no other args, as you've noticed.
Perhaps this is an indicator that we need two different tools.  I've
thought for years that we need a 'guix develop' (working title) tool
that does what 'guix shell' does but also goes beyond by starting
containerized services like 'docker compose' can. For example, if a
project requires a PostgreSQL database, 'guix develop' could create a
shell environment with the client program/library but also
automatically start the server using an instance of Shepherd and
'herd' inside the shell could be used to control the service.

- Dave