Hi!
Sarah Morgensen <iskar...@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’.
