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