Re: Named environments

["Ludovic Courtès" <ludo@gnu.org>]

Hi!

Sarah Morgensen <iskarian@mgsn.dev> skribis:

> However, an actual `guix env' could do a lot more!  Like you allude to, being
> able to essentially save the options of a `guix environment' invocation would
> be great:
>
>   $ guix env --edit @test <lots of packages and environment options>
>   $ guix env @test -- pytest

Perhaps not as convenient (although that’s a matter of taste), but that
sounds similar to:

  guix environment -m test-manifest.scm -- pytest

WDYT?  Perhaps there’s a need for a more lightweight CLI?

> But also imagine portable environments (used, for example, for project dev
> environments, checked in with the source):
>
> $ guix env --export @myapp-test --pure -C -f guix.scm --ad-hoc strace coreutils
>
> (environment "@myapp-test"
>  (load '("guix.scm"))
>  (ad-hoc-packages '("strace" "coreutils" "findutils")) 
>  (flags '(pure container)))

Like zimoun write, we could make ‘--export-profile’ somehow available to
‘guix environment’.

> Of course, this isn't entirely reproducible, as packages could change as you
> update your Guix, even if you give a version spec (the same issue that exists
> for manifests).  So, we could pin the channel used to make the environment:
>
> $ guix env --export @myapp-test --pin-channels ...
>
> (environment "@myapp-test"
>  (channels (list (channel (name 'guix)
>                           (url ...)
>                           (commit ...)))
>  (load '("guix.scm"))
>  (ad-hoc-packages '("strace" "coreutils" "findutils")) 
>  (flags '(pure container))))
>
> which, when evaluated, would internally do what `guix time-machine --channels
> file' does.

While it’s tempting to do both at once, I think channels and
environments should remain separate things, at least for now, because
the implications and cost differ significantly.

Thanks,
Ludo’.