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