* Re: The future of 'guix environment'
2017-08-30 13:22 The future of 'guix environment' Thompson, David
@ 2017-08-30 15:11 ` 宋文武
2017-08-30 15:33 ` Leo Famulari
` (2 more replies)
2017-08-30 15:52 ` Andreas Enge
` (3 subsequent siblings)
4 siblings, 3 replies; 24+ messages in thread
From: 宋文武 @ 2017-08-30 15:11 UTC (permalink / raw)
To: Thompson, David; +Cc: guix-devel
"Thompson, David" <dthompson2@worcester.edu> writes:
> Hi all, been awhile!
Yeah, glad to see you!
> [...]
>
> 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.
I always run 'guix environmeut guix' and have to wait for substitutes
before entering the shell, indeed caching the environment will save me
much time, but usually I don't mind that and was already used to the
"awlays being latest" behaviour...
I definitely want this feature too, so how about rename the current
implementation of 'environment' to 'guix shell', whose ad hoc behaviour
is similar to the 'nix-shell', and start a new implementation with this
persistent behaviour?
>
> 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.
>
> 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.
I would expect a config file is mandatory and default to something like
'environment.scm' in the current directory, and a '--config' option can
be used to choose other location. This 'environment' command don't have
many command line options (ad-hoc in nature), while the config file can
do a lot.
>
> 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.
Yeah, split them into 2 commands will be more clear :-)
>
> 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.
Yes, maybe launch the services with a subcommand like 'guix environment
up', so the shell entering 'guix environment' command can be run
multiple times.
>
> 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'.
>
> Thoughts?
Indeed very useful, looking forward to it!
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-08-30 15:11 ` 宋文武
@ 2017-08-30 15:33 ` Leo Famulari
2017-08-30 15:43 ` Ricardo Wurmus
2017-08-30 15:56 ` Andreas Enge
2 siblings, 0 replies; 24+ messages in thread
From: Leo Famulari @ 2017-08-30 15:33 UTC (permalink / raw)
To: 宋文武; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]
On Wed, Aug 30, 2017 at 11:11:33PM +0800, 宋文武 wrote:
> > 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.
I like that the results of `guix environment` are ephemeral by default.
> I always run 'guix environmeut guix' and have to wait for substitutes
> before entering the shell, indeed caching the environment will save me
> much time, but usually I don't mind that and was already used to the
> "awlays being latest" behaviour...
>
> I definitely want this feature too, so how about rename the current
> implementation of 'environment' to 'guix shell', whose ad hoc behaviour
> is similar to the 'nix-shell', and start a new implementation with this
> persistent behaviour?
I agree. If we change the behaviour to leave files in the current
directory and register GC roots then we should use a new name or rename
the existing functionality. I'm in favor of using a new name for new
functionality.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
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
2 siblings, 1 reply; 24+ messages in thread
From: Ricardo Wurmus @ 2017-08-30 15:43 UTC (permalink / raw)
To: 宋文武; +Cc: guix-devel
宋文武 <iyzsong@member.fsf.org> writes:
>> 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.
>
> Yes, maybe launch the services with a subcommand like 'guix environment
> up', so the shell entering 'guix environment' command can be run
> multiple times.
AFAIU the proposal, that’s precisely what we don’t want. Dave wants
users/developers to be able to specify the behaviour of the environment,
not just the packages that ought to be available. I’d expect all
services to be killed upon leaving the environment, so we don’t need to
have a separate command for bringing them up.
It is not clear to me if it should be possible to “attach” to an
environment that is “active” in another shell session (like it is
possible with Docker containers).
@Dave: I pretty much agree with all of the proposed changes. One thing
that may be lost, though, when using a new <guix-environment> record is
easy ad-hoc packaging.
Now I can use a guix.scm file both for building a Guix package and a
Docker image; I would expect that it would no longer be possible to
build a Guix package out of an environment file. On the other hand,
building a more fully featured container image would be even simpler
with this change.
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-08-30 15:43 ` Ricardo Wurmus
@ 2017-08-31 15:00 ` Ludovic Courtès
0 siblings, 0 replies; 24+ messages in thread
From: Ludovic Courtès @ 2017-08-31 15:00 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: guix-devel
Hello!
Ricardo Wurmus <rekado@elephly.net> skribis:
> @Dave: I pretty much agree with all of the proposed changes. One thing
> that may be lost, though, when using a new <guix-environment> record is
> easy ad-hoc packaging.
>
> Now I can use a guix.scm file both for building a Guix package and a
> Docker image; I would expect that it would no longer be possible to
> build a Guix package out of an environment file. On the other hand,
> building a more fully featured container image would be even simpler
> with this change.
I think the new command could automatically convert <package> to
<environment>, such that you can still have a guix.scm file that defines
a package and can be passed both to ‘guix package -f’ and ‘guix
environment’.
Ludo’.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-08-30 15:11 ` 宋文武
2017-08-30 15:33 ` Leo Famulari
2017-08-30 15:43 ` Ricardo Wurmus
@ 2017-08-30 15:56 ` Andreas Enge
2017-08-31 1:28 ` Thompson, David
2 siblings, 1 reply; 24+ messages in thread
From: Andreas Enge @ 2017-08-30 15:56 UTC (permalink / raw)
To: 宋文武; +Cc: guix-devel
Hello,
On Wed, Aug 30, 2017 at 11:11:33PM +0800, 宋文武 wrote:
> I definitely want this feature too, so how about rename the current
> implementation of 'environment' to 'guix shell', whose ad hoc behaviour
> is similar to the 'nix-shell', and start a new implementation with this
> persistent behaviour?
I think we should not have too many commands to Guix, especially not with
similar behaviour, since this will make the tool too confusing. How about
adding command line options?
For instance:
1) Do not cache by default, cache when "--cache" is given.
2) Maybe even better, use "--cache=XXX" to cache under the name or number XXX.
3) Then later, add "--resume" or "--resume=XXX".
Or do something similar to "git stash", piling up environments on a stack
and popping or dropping them.
Andreas
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-08-30 15:56 ` Andreas Enge
@ 2017-08-31 1:28 ` Thompson, David
2017-09-01 3:57 ` Christopher Allan Webber
0 siblings, 1 reply; 24+ messages in thread
From: Thompson, David @ 2017-08-31 1:28 UTC (permalink / raw)
To: Andreas Enge; +Cc: guix-devel
Thanks for the feedback, everyone. I'm going to try to address what
everyone has been discussing.
宋文武, I agree with Andreas that making a new command is undesirable and
would just lead to confusion. I think a single tool can support the
major use cases well. I'd go so far as to say that I will have failed
if two commands are necessary. We can always add subcommands to 'guix
environment' itself, if that turns out to be better for usability. We
will see.
As for a 'guix environment up' command, I think that's worth thinking
about but I'm going to avoid thinking about it too much because we're
still quite a ways off from being able to make this happen. My
general feeling is the same as Ricardo's, though, that 'guix
environment' should just spawn the services automatically and there
would have to be some notion of "attaching" to an existing session.
This topic deserves a whole separate thread when the time comes.
Ricardo, you are correct that we would lose the ability to use the
guix.scm file for both 'guix environment' and 'guix build'. In
practice I don't actually use my guix.scm file this way, so I think
it's worth breaking, but maybe you (or someone else) actually uses
this and we should think more about it?
I wasn't very clear about whether ephemeral or cached would be the new
default. I don't think there is one default for all cases, I think
it's more context sensitive. When the user specifies --load, I think
caching should be the default because loading such a file means that
you are working on a project for which you'd like a persistent
environment. When the user specifies ad-hoc packages, caching would
be disabled because most likely they are running a one-off job. For
example, 'guix environment ruby -- irb' should spawn a Ruby REPL,
discarding the environment when the user exits. 'guix environment
--load=guix.scm' would check for a cached profile, use it if it is
there, otherwise build the profile and cache it for next time. 'guix
environment', without --load or any packages specified, would be
equivalent to 'guix environment --load=guix.scm'. A little
"convention over configuration" will greatly improve usability, I
think. There's really only 2 major use cases, and I want those to
work without having to fiddle with a bunch of command line flags. All
the underlying flags will still be there to fiddle with for those who
are interested.
- Dave
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
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
0 siblings, 2 replies; 24+ messages in thread
From: Christopher Allan Webber @ 2017-09-01 3:57 UTC (permalink / raw)
To: Thompson, David; +Cc: guix-devel
Thompson, David writes:
> Ricardo, you are correct that we would lose the ability to use the
> guix.scm file for both 'guix environment' and 'guix build'. In
> practice I don't actually use my guix.scm file this way, so I think
> it's worth breaking, but maybe you (or someone else) actually uses
> this and we should think more about it?
I do use guix.scm for testing `guix build'. Maybe I ma the only one
though. It turns out to be very useful to find out whether or not I've
done something that borked my package that's not obvious because I have
some compiled .go file around in working directory or something.
> I wasn't very clear about whether ephemeral or cached would be the new
> default. I don't think there is one default for all cases, I think
> it's more context sensitive.
I'm a bit confused by caching, but IMO maybe the right solution is
actually guix environment for "environment profiles". Ie, I want to be
able to update my guix environment and if it turns out I made a mistake
easily roll back, just like I can with my user's profile. Currently
you can use --root, but you don't have the generations support.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-09-01 3:57 ` Christopher Allan Webber
@ 2017-09-01 13:15 ` Thompson, David
2017-09-02 21:06 ` Ludovic Courtès
1 sibling, 0 replies; 24+ messages in thread
From: Thompson, David @ 2017-09-01 13:15 UTC (permalink / raw)
To: Christopher Allan Webber; +Cc: guix-devel
On Thu, Aug 31, 2017 at 11:57 PM, Christopher Allan Webber
<cwebber@dustycloud.org> wrote:
> Thompson, David writes:
>
>> Ricardo, you are correct that we would lose the ability to use the
>> guix.scm file for both 'guix environment' and 'guix build'. In
>> practice I don't actually use my guix.scm file this way, so I think
>> it's worth breaking, but maybe you (or someone else) actually uses
>> this and we should think more about it?
>
> I do use guix.scm for testing `guix build'. Maybe I ma the only one
> though. It turns out to be very useful to find out whether or not I've
> done something that borked my package that's not obvious because I have
> some compiled .go file around in working directory or something.
Ludovic's suggestion of supporting both package and environment
objects with --load will solve the issue.
>> I wasn't very clear about whether ephemeral or cached would be the new
>> default. I don't think there is one default for all cases, I think
>> it's more context sensitive.
>
> I'm a bit confused by caching, but IMO maybe the right solution is
> actually guix environment for "environment profiles". Ie, I want to be
> able to update my guix environment and if it turns out I made a mistake
> easily roll back, just like I can with my user's profile. Currently
> you can use --root, but you don't have the generations support.
This is what caching would allow.
- Dave
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
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
1 sibling, 1 reply; 24+ messages in thread
From: Ludovic Courtès @ 2017-09-02 21:06 UTC (permalink / raw)
To: Christopher Allan Webber; +Cc: guix-devel
Hi Chris,
Christopher Allan Webber <cwebber@dustycloud.org> skribis:
> Thompson, David writes:
>
>> Ricardo, you are correct that we would lose the ability to use the
>> guix.scm file for both 'guix environment' and 'guix build'. In
>> practice I don't actually use my guix.scm file this way, so I think
>> it's worth breaking, but maybe you (or someone else) actually uses
>> this and we should think more about it?
>
> I do use guix.scm for testing `guix build'. Maybe I ma the only one
> though. It turns out to be very useful to find out whether or not I've
> done something that borked my package that's not obvious because I have
> some compiled .go file around in working directory or something.
I use it too, occasionally! :-)
I use a feature that maybe no one else uses, which is to have guix.scm
return a gexp. I found it to be a relatively nice way to do
makefile-like things, like building the web site:
http://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/guix.scm
Ludo’.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-09-02 21:06 ` Ludovic Courtès
@ 2017-09-03 7:15 ` Jan Nieuwenhuizen
2017-09-05 12:42 ` Thompson, David
0 siblings, 1 reply; 24+ messages in thread
From: Jan Nieuwenhuizen @ 2017-09-03 7:15 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Ludovic Courtès writes:
>> I do use guix.scm for testing `guix build'. Maybe I ma the only one
>> though. It turns out to be very useful to find out whether or not I've
>> done something that borked my package that's not obvious because I have
>> some compiled .go file around in working directory or something.
>
> I use it too, occasionally! :-)
Me too! It's great to test if all is fine. What I'm also using is your
git-file? hack
https://git.dthompson.us/guile-sdl2.git/blob/HEAD:/guix.scm
does anyone see a nice way to put that function/functionaly in guix?
Greetings,
janneke
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-09-03 7:15 ` Jan Nieuwenhuizen
@ 2017-09-05 12:42 ` Thompson, David
2017-09-05 14:34 ` Ludovic Courtès
0 siblings, 1 reply; 24+ messages in thread
From: Thompson, David @ 2017-09-05 12:42 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: guix-devel
On Sun, Sep 3, 2017 at 3:15 AM, Jan Nieuwenhuizen <janneke@gnu.org> wrote:
> Ludovic Courtès writes:
>
>>> I do use guix.scm for testing `guix build'. Maybe I ma the only one
>>> though. It turns out to be very useful to find out whether or not I've
>>> done something that borked my package that's not obvious because I have
>>> some compiled .go file around in working directory or something.
>>
>> I use it too, occasionally! :-)
>
> Me too! It's great to test if all is fine. What I'm also using is your
> git-file? hack
>
> https://git.dthompson.us/guile-sdl2.git/blob/HEAD:/guix.scm
>
> does anyone see a nice way to put that function/functionaly in guix?
git-file? was snarfed from some internal Guix code that Ludovic wrote.
I would also like to see a public API for it.
- Dave
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-09-05 12:42 ` Thompson, David
@ 2017-09-05 14:34 ` Ludovic Courtès
0 siblings, 0 replies; 24+ messages in thread
From: Ludovic Courtès @ 2017-09-05 14:34 UTC (permalink / raw)
To: Thompson, David; +Cc: guix-devel
"Thompson, David" <dthompson2@worcester.edu> skribis:
> On Sun, Sep 3, 2017 at 3:15 AM, Jan Nieuwenhuizen <janneke@gnu.org> wrote:
>> Ludovic Courtès writes:
>>
>>>> I do use guix.scm for testing `guix build'. Maybe I ma the only one
>>>> though. It turns out to be very useful to find out whether or not I've
>>>> done something that borked my package that's not obvious because I have
>>>> some compiled .go file around in working directory or something.
>>>
>>> I use it too, occasionally! :-)
>>
>> Me too! It's great to test if all is fine. What I'm also using is your
>> git-file? hack
>>
>> https://git.dthompson.us/guile-sdl2.git/blob/HEAD:/guix.scm
>>
>> does anyone see a nice way to put that function/functionaly in guix?
>
> git-file? was snarfed from some internal Guix code that Ludovic wrote.
> I would also like to see a public API for it.
It’s ‘git-predicate’ in (guix git-download).
Ludo’.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-08-30 13:22 The future of 'guix environment' Thompson, David
2017-08-30 15:11 ` 宋文武
@ 2017-08-30 15:52 ` Andreas Enge
2017-08-31 7:18 ` Jan Nieuwenhuizen
` (2 subsequent siblings)
4 siblings, 0 replies; 24+ messages in thread
From: Andreas Enge @ 2017-08-30 15:52 UTC (permalink / raw)
To: Thompson, David; +Cc: guix-devel
Hello David,
thanks for your thoughts!
On Wed, Aug 30, 2017 at 09:22:13AM -0400, Thompson, David wrote:
> As an avid Emacs user, I want to do everything in Emacs, but if I want
> to use, say, M-x compile but in the context of my development
> environment, I have to wrap the command in 'guix environment' and now
> everything takes way longer because Guix wastes tons of time talking
> to the daemon to build a profile that I know already exists. This
> goes hand in hand with the previous issue. We need a cache.
From the remainder of your message, I get the impression that exactly one
environment is cached?
As Leo, I use "guix environment" only ephemerally, as "guix environment foo"
when I quickly want to build or work on package foo (which, most of the
time, equals "guix"...). So an option of no cache would be nice as well.
On the other hand, could there be several cached environments?
Numbered or otherwise identified, for people who alternate between two
different projects? Would this be an interesting use case?
> The default behavior of 'guix environment foo' creating an environment
> with the *dependencies* of the package 'foo' seemed like a good idea
> at the time (it's what nix-shell did, after all), but most of the time
> when I define throwaway environments on the command-line (as opposed
> to a guix.scm file) I *always* use the --ad-hoc flag. Using the
> packages themselves rather than the dependencies should be the
> default.
Indeed, before getting used to it, I found this behaviour very counter-
intuitive, so I like the new defaults you suggest, with reversed command
line flags.
Andreas
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-08-30 13:22 The future of 'guix environment' Thompson, David
2017-08-30 15:11 ` 宋文武
2017-08-30 15:52 ` Andreas Enge
@ 2017-08-31 7:18 ` Jan Nieuwenhuizen
2017-08-31 13:28 ` Thompson, David
2017-08-31 15:16 ` Ludovic Courtès
2017-09-01 3:52 ` Christopher Allan Webber
4 siblings, 1 reply; 24+ messages in thread
From: Jan Nieuwenhuizen @ 2017-08-31 7:18 UTC (permalink / raw)
To: Thompson, David; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 734 bytes --]
Thompson, David writes:
> Hi all, been awhile!
Hi David!
Great suggestions all! I use guix environment heavily and like it a
lot.
> 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.
Wouldn't that be
guix environment --cache --dependencies --load=guix.scm
I have been using an ugly hack to switch profiles (or environments; look
at $GUIX_ENVIRONMENT) in Emacs, see attached. As discussed briefly on
irc yesterday are various ways this could go: use emacs-direnv, read the
manifest file in elisp, use guix repl to read it..etc
Greetings,
janneke
[-- Attachment #2: guix-environment.el --]
[-- Type: application/emacs-lisp, Size: 700 bytes --]
[-- Attachment #3: Type: text/plain, Size: 152 bytes --]
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-08-31 7:18 ` Jan Nieuwenhuizen
@ 2017-08-31 13:28 ` Thompson, David
2017-09-01 11:50 ` Jan Nieuwenhuizen
0 siblings, 1 reply; 24+ messages in thread
From: Thompson, David @ 2017-08-31 13:28 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: guix-devel
On Thu, Aug 31, 2017 at 3:18 AM, Jan Nieuwenhuizen <janneke@gnu.org> wrote:
> Thompson, David writes:
>
>> Hi all, been awhile!
>
> Hi David!
>
> Great suggestions all! I use guix environment heavily and like it a
> lot.
Thanks!
>> 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.
>
> Wouldn't that be
>
> guix environment --cache --dependencies --load=guix.scm
No, because guix.scm would no longer evaluate to a package object, but
an environment object. Flags like --dependencies are for environments
defined on the fly at the command line. I haven't yet decided if
--load should be mutually exclusive from all those other things, but I
think that should probably be the case. Perhaps introducing
subcommands is the best thing UX-wise. 'guix environment load
guix.scm', 'guix environment shell direnv --dependencies ruby', and
'guix environment' would be a shorthand for 'guix environment load'.
This will take some fiddling to see. I'm going to get the core
features implemented first, then work on the UX.
> I have been using an ugly hack to switch profiles (or environments; look
> at $GUIX_ENVIRONMENT) in Emacs, see attached. As discussed briefly on
> irc yesterday are various ways this could go: use emacs-direnv, read the
> manifest file in elisp, use guix repl to read it..etc
I took a look at emacs-direnv and did not like it because it's not
fully implemented in elisp. You also need the direnv tool itself,
which is written in Go. No thanks! I think the integration should
happen with emacs-guix, which could use the Guile REPL to read the
profile manifest, and send an sexp back to Emacs with key/value pairs
for the values of all environment variables. From there it's easy to
use setenv and tweak exec-path in the case of $PATH. Alex Kost would
know a lot better than I about how to get this done.
- Dave
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-08-31 13:28 ` Thompson, David
@ 2017-09-01 11:50 ` Jan Nieuwenhuizen
2017-09-01 12:08 ` Ricardo Wurmus
2017-09-01 13:13 ` Thompson, David
0 siblings, 2 replies; 24+ messages in thread
From: Jan Nieuwenhuizen @ 2017-09-01 11:50 UTC (permalink / raw)
To: Thompson, David; +Cc: guix-devel
Thompson, David writes:
>> Wouldn't that be
>>
>> guix environment --cache --dependencies --load=guix.scm
>
> No, because guix.scm would no longer evaluate to a package object, but
> an environment object.
Ah, nice. Thank for the explanation!
One thing I didn't see in your proposal is something like
guix environment --manifest manifest.scm
It really bothers me that I can only declaritavely populate/maintain
named profiles. Do you have an idea about that?
> I took a look at emacs-direnv and did not like it because it's not
> fully implemented in elisp. You also need the direnv tool itself,
> which is written in Go. No thanks!
No thanks here too. A yoghurt language just to run a shell, ugh.
Greetings,
janneke
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
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
1 sibling, 1 reply; 24+ messages in thread
From: Ricardo Wurmus @ 2017-09-01 12:08 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: guix-devel
Jan Nieuwenhuizen <janneke@gnu.org> writes:
> Thompson, David writes:
>> […] which is written in Go. No thanks!
>
> No thanks here too. A yoghurt language just to run a shell, ugh.
The term “yoghurt […]” for software with bootstrapping problems will be
mainstream any day now :)
(But isn’t Go actually okay in terms of bootstrapping thanks to the GCC
implementation?)
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-09-01 11:50 ` Jan Nieuwenhuizen
2017-09-01 12:08 ` Ricardo Wurmus
@ 2017-09-01 13:13 ` Thompson, David
1 sibling, 0 replies; 24+ messages in thread
From: Thompson, David @ 2017-09-01 13:13 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: guix-devel
On Fri, Sep 1, 2017 at 7:50 AM, Jan Nieuwenhuizen <janneke@gnu.org> wrote:
>
> One thing I didn't see in your proposal is something like
>
> guix environment --manifest manifest.scm
>
> It really bothers me that I can only declaritavely populate/maintain
> named profiles. Do you have an idea about that?
Never thought about it before. Maybe --load could support evaluating
to a package, a manifest, or an environment? Seems like that might be
getting into crazy territory, but maybe not.
- Dave
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-08-30 13:22 The future of 'guix environment' Thompson, David
` (2 preceding siblings ...)
2017-08-31 7:18 ` Jan Nieuwenhuizen
@ 2017-08-31 15:16 ` Ludovic Courtès
2017-09-01 0:29 ` Thompson, David
2017-09-01 3:52 ` Christopher Allan Webber
4 siblings, 1 reply; 24+ messages in thread
From: Ludovic Courtès @ 2017-08-31 15:16 UTC (permalink / raw)
To: Thompson, David; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-08-31 15:16 ` Ludovic Courtès
@ 2017-09-01 0:29 ` Thompson, David
2017-09-02 21:09 ` Ludovic Courtès
0 siblings, 1 reply; 24+ messages in thread
From: Thompson, David @ 2017-09-01 0:29 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
On Thu, Aug 31, 2017 at 11:16 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> 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?
Yeah, I guess so. I've never used the -p flag and don't know if it
should stay. I'll try to preserve it and see how that goes!
> 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?
Yes. For regularly hacked on project environments I think this is the
most useful behavior. Because then, much like my regular user
profile, I can update at a time when I feel ready to do so, rather the
current situation where I'm forced to rebuild and deal with potential
breakage or long download/compile times.
> 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?
That's what I had in mind. In my head there's two important cases:
the on-the-fly, stateless environment, and the persistent environment
that you update every now and then when you feel like living on the
edge. 'guix environment foo bar' (ad-hoc being the new default)
should absolutely be stateless, just like it is now.
>> 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.
Ah, this is a clever hack! I will do that. Thanks for suggesting it.
>> 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.
I think I will convince you it's a good idea. ;)
> 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.)
Sure, that's fine with me, but FYI there are existing conventions of
using non-hidden files. Bundler uses 'Gemfile', Docker uses
'Dockerfile', Vagrant uses 'Vagrantfile', npm uses 'package.json',
etc.
> Bonus: honor “.guix.json” (see <https://bugs.gnu.org/28251>) as one way
> to get us closer to world domination.
Maybe someone else can add that after I do everything else. :)
> 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.
I agree. We can discuss more when I have patches. I will probably
have additional questions as I go. The biggest unknown for me so far
is how environment profile generation management will work (if it
should even exist), but I'll get the basics sorted out first.
Thanks for your feedback!
- Dave
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-09-01 0:29 ` Thompson, David
@ 2017-09-02 21:09 ` Ludovic Courtès
0 siblings, 0 replies; 24+ messages in thread
From: Ludovic Courtès @ 2017-09-02 21:09 UTC (permalink / raw)
To: Thompson, David; +Cc: guix-devel
Howdy!
"Thompson, David" <dthompson2@worcester.edu> skribis:
> On Thu, Aug 31, 2017 at 11:16 AM, Ludovic Courtès <ludo@gnu.org> wrote:
[...]
>> 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?
>
> Yes. For regularly hacked on project environments I think this is the
> most useful behavior. Because then, much like my regular user
> profile, I can update at a time when I feel ready to do so, rather the
> current situation where I'm forced to rebuild and deal with potential
> breakage or long download/compile times.
Agreed, that makes sense.
>> 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?
>
> That's what I had in mind. In my head there's two important cases:
> the on-the-fly, stateless environment, and the persistent environment
> that you update every now and then when you feel like living on the
> edge. 'guix environment foo bar' (ad-hoc being the new default)
> should absolutely be stateless, just like it is now.
Perfect. So “guix environment” with no arguments would almost be a
wrapper around “guix package -p”, I think (with generations, upgrades,
etc.)
>> 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.)
>
> Sure, that's fine with me, but FYI there are existing conventions of
> using non-hidden files. Bundler uses 'Gemfile', Docker uses
> 'Dockerfile', Vagrant uses 'Vagrantfile', npm uses 'package.json',
> etc.
Oh right. “Guixfile” then!
(Just kidding.)
Thanks!
Ludo’.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: The future of 'guix environment'
2017-08-30 13:22 The future of 'guix environment' Thompson, David
` (3 preceding siblings ...)
2017-08-31 15:16 ` Ludovic Courtès
@ 2017-09-01 3:52 ` Christopher Allan Webber
4 siblings, 0 replies; 24+ messages in thread
From: Christopher Allan Webber @ 2017-09-01 3:52 UTC (permalink / raw)
To: Thompson, David; +Cc: guix-devel
Not going to reply in detail, but I'm a devoted user of `guix
environment' and I support all these changes!
^ permalink raw reply [flat|nested] 24+ messages in thread