From: ludo@gnu.org (Ludovic Courtès)
To: "Thompson, David" <dthompson2@worcester.edu>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: The future of 'guix environment'
Date: Thu, 31 Aug 2017 17:16:39 +0200 [thread overview]
Message-ID: <87inh3n4x4.fsf@gnu.org> (raw)
In-Reply-To: <CAJ=RwfZZXF1Pk8quPbtNGkn10NU==ZqYhmj6nn1B8s-FgH2xwQ@mail.gmail.com> (David Thompson's message of "Wed, 30 Aug 2017 09:22:13 -0400")
Heya,
"Thompson, David" <dthompson2@worcester.edu> skribis:
> If you've followed along this far, great! Now here's my list of
> proposed changes:
>
> 1) Add a caching mechanism. The environment profile should get built
> once, and then a symlink to it should be created in $PWD and
> registered as a GC root. This will, of course, require re-using some
> 'guix package' code to delete the profile. For the sake of the rest
> of this post, let's say that a --cache flag does this, and a --update
> flag forces a rebuilding of the cached profile.
One way to put it is that ‘guix environment’ would be syntactic sugar
for ‘guix package -p $PWD/.guix-environment’, right?
This would make “guix environment” stateful: if you have something in
cache, that’s what you get (it could be old versions of “foo” and
“bar”), but if you don’t, you get the current versions of “foo” and
“bar”. Is this what you have in mind?
I prefer the current stateless behavior, whereby “guix environment
--ad-hoc foo bar” always gives you the same environment, given a Guix
commit. But maybe we can make “guix environment” (no arguments)
stateful, and keep “guix environment foo bar baz” stateless?
> 2) Make "ad-hoc" the default. Remove the --ad-hoc flag and replace it
> with a --dependencies flag instead, reversing the current behavior.
> 'guix environment --dependencies guix' would create a guix dev
> environment, for example.
+1
> 3) Change how --load behaves. Instead of evaluating a file and
> expected a package object in return, instead expect a
> <guix-environment> record. This would provide a declarative way to
> specify the complete environment: which packages to pull in, whether
> to purify the environment (--pure), whether to run in a container
> (--container), whether to give the container network access
> (--network), etc. Command line flags would take precedence over what
> is specified in the config file. --load may only appear *once* in the
> command line args, whereas now it many appear N times.
+1, probably with automatic conversion of <package> to <environment>, as
I wrote in another message.
> 4) Make 'guix environment' with no other args operate like 'guix
> environment --cache --load=guix.scm'. 'guix.scm' is a placeholder
> name for whatever we decide the conventional name for an environment
> config should be. Throwaway environments (such as 'guix environment
> ruby -- irb') would not have caching turned on by default, because
> that would quickly become a burden.
+1, except perhaps for --cache, not sure.
Also, I would prefer the convention to be “.guix.scm” (to avoid
confusion with the (guix) module, and to mimic existing conventions
followed by Travis and all that.)
Bonus: honor “.guix.json” (see <https://bugs.gnu.org/28251>) as one way
to get us closer to world domination.
> 5) Add support for Shepherd services. When an environment is created,
> a new Shepherd process is launched to handle all the necessary
> services. For a web application this could be nginx, mysql, redis,
> etc. This feature can be implemented later, even post 1.0, provided
> we agree upon using a <guix-environment> record type.
Yup.
> After all these changes, a Guix user should be able to jump into a new
> project, run 'guix environment' and be ready to go. When they update
> Guix and want to refresh their environment, they would run 'guix
> environment --update'.
These all sound like great proposals!
I’d rather not add a new command, which means we’ll have to agree to
break the “guix environment” CLI. I think that’s OK, but we should
discuss it.
Thank you!
Ludo’.
next prev parent reply other threads:[~2017-08-31 15:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-30 13:22 The future of 'guix environment' Thompson, David
2017-08-30 15:11 ` 宋文武
2017-08-30 15:33 ` Leo Famulari
2017-08-30 15:43 ` Ricardo Wurmus
2017-08-31 15:00 ` Ludovic Courtès
2017-08-30 15:56 ` Andreas Enge
2017-08-31 1:28 ` Thompson, David
2017-09-01 3:57 ` Christopher Allan Webber
2017-09-01 13:15 ` Thompson, David
2017-09-02 21:06 ` Ludovic Courtès
2017-09-03 7:15 ` Jan Nieuwenhuizen
2017-09-05 12:42 ` Thompson, David
2017-09-05 14:34 ` Ludovic Courtès
2017-08-30 15:52 ` Andreas Enge
2017-08-31 7:18 ` Jan Nieuwenhuizen
2017-08-31 13:28 ` Thompson, David
2017-09-01 11:50 ` Jan Nieuwenhuizen
2017-09-01 12:08 ` Ricardo Wurmus
2017-09-01 12:25 ` Jan Nieuwenhuizen
2017-09-01 13:13 ` Thompson, David
2017-08-31 15:16 ` Ludovic Courtès [this message]
2017-09-01 0:29 ` Thompson, David
2017-09-02 21:09 ` Ludovic Courtès
2017-09-01 3:52 ` Christopher Allan Webber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87inh3n4x4.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=dthompson2@worcester.edu \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.