guix shell without arguments

guix shell without arguments

[André A. Gomes]

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

Thanks.


-- 
André A. Gomes
"You cannot even find the ruins..."

Re: guix shell without arguments

[Simon Tournier]

Hi,

On ven., 12 mai 2023 at 14:06, André A. Gomes <andremegafone@gmail.com> wrote:

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

That’s already the case, no?   From the manual:

    If it finds a manifest.scm in the current working directory or any
    of its parents, it uses this manifest as though it was given via
    --manifest. Likewise, if it finds a guix.scm in the same
    directories, it uses it to build a development profile as though
    both --development and --file were present. In either case, the file
    will only be loaded if the directory it resides in is listed in
    ~/.config/guix/shell-authorized-directories. This provides an easy
    way to define, share, and enter development environments.

    <https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-shell>

Is it a regression?

Cheers,
simon

Re: guix shell without arguments

[Thompson, David]

Hi Simon,

On Fri, May 12, 2023 at 12:10 PM Simon Tournier
<zimon.toutoune@gmail.com> wrote:
>
> Hi,
>
> On ven., 12 mai 2023 at 14:06, André A. Gomes <andremegafone@gmail.com> wrote:
>
> > --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---
>
> That’s already the case, no?   From the manual:
>
>     If it finds a manifest.scm in the current working directory or any
>     of its parents, it uses this manifest as though it was given via
>     --manifest. Likewise, if it finds a guix.scm in the same
>     directories, it uses it to build a development profile as though
>     both --development and --file were present. In either case, the file
>     will only be loaded if the directory it resides in is listed in
>     ~/.config/guix/shell-authorized-directories. This provides an easy
>     way to define, share, and enter development environments.
>
>     <https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-shell>
>
> Is it a regression?

It *sounds* like it should be the case, but it isn't. Specifying the
command to run explicitly is considered a non-interactive case, and in
non-interactive mode the automagic guix.scm/manifest.scm reading does
not occur. :(

- Dave

Re: guix shell without arguments

[Simon Tournier]

Hi Dave,

On Fri, 12 May 2023 at 12:14, "Thompson, David" <dthompson2@worcester.edu> wrote:

> It *sounds* like it should be the case, but it isn't. Specifying the
> command to run explicitly is considered a non-interactive case, and in
> non-interactive mode the automagic guix.scm/manifest.scm reading does
> not occur. :(

Oh, I see.  Thanks for the reminder <https://issues.guix.gnu.org/57467>.

Hum, as you note in [1], maybe there are 2 tools with contradictory
needs.  Well, I think that GUIX_EXTENSIONS_PATHS is not enough used as a
mean for testing new CLI.  I mean, we could imagine an extension that
would be installable as a regular package and then it would provide the
CLI you would like.  Well, I do not know if it is a good idea to
overwrite built-in commands but extensions would allow to test various
CLI, IMHO.

1: https://yhetil.org/guix/CAJ=RwfaYrJqcREgbww_XmfBzsfTjF+9tiLm2Zb0N9Dq8puS=SA@mail.gmail.com


Cheers,
simon

Re: guix shell without arguments

[André A. Gomes]

Simon Tournier <zimon.toutoune@gmail.com> writes:

> On ven., 12 mai 2023 at 14:06, André A. Gomes <andremegafone@gmail.com> wrote:

>> 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---
>
> That’s already the case, no?   From the manual:
>
>     If it finds a manifest.scm in the current working directory or any
>     of its parents, it uses this manifest as though it was given via
>     --manifest. Likewise, if it finds a guix.scm in the same
>     directories, it uses it to build a development profile as though
>     both --development and --file were present. In either case, the file
>     will only be loaded if the directory it resides in is listed in
>     ~/.config/guix/shell-authorized-directories. This provides an easy
>     way to define, share, and enter development environments.
>
>     <https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-shell>
>
> Is it a regression?

Hello Simon,

Indeed, I have interpreted that section from the manual in the same as
you did.  However, as I've mentioned in the previous message, "guix
shell -- foo-command" creates an empty environment and then runs
foo-command (regardless of the existence of guix/manifest.scm).

I don't think it ever behaved otherwise, and this seems to be backed by
Dave's message.  Dave, indeed, I belong to that 1st group of people that
expect a DWIM behaviour.

Thanks.

-- 
André A. Gomes
"You cannot even find the ruins..."

Re: guix shell without arguments

[Thompson, David]

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

Re: guix shell without arguments

[Hafeez Bana]

Side question. How do people run poostgresql run right that’s been
installed via guix?

Asking because I am packaging  freeswitch and freeswitch the install (in
gnu store) is different from freeswitch the process which needs a working
config and log directory.

My plan is to create a seperate ops folder and start the process via
shepherd. But wondering if I am doing something custom when people have
thought this through before me?



On Fri, 12 May 2023 at 14:10, Thompson, David <dthompson2@worcester.edu>
wrote:

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

Re: guix shell without arguments

[Felix Lechner via]

Hi Hafeez,

On Sat, May 13, 2023 at 11:23 PM Hafeez Bana <hafeez.bana@gmail.com> wrote:
>
> How do people run poostgresql run right that’s been
> installed via guix?

I start it via postgresql-service-type. [1]

Kind regards
Felix

[1] https://codeberg.org/lechner/system-config/src/commit/bba3636982400ef6a82e902dd2771e8c82b22894/host/wallace-server/operating-system.scm#L657-L675