[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guix shell without arguments

From: Hafeez Bana
Subject: Re: guix shell without arguments
Date: Fri, 12 May 2023 15:17:30 +0100

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

> Hi Andre,
> On Fri, May 12, 2023 at 7:07 AM André A. Gomes <>
> 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:
> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]