[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Named environments
From: |
Ryan Prior |
Subject: |
Re: Named environments |
Date: |
Tue, 14 Sep 2021 02:32:17 +0000 |
On Monday, September 13th, 2021 at 3:48 PM, pinoaffe <pinoaffe@airmail.cc>
wrote:
> this sounds very similar to the features offered by profiles
Agreed, and maybe it's good to unify these things or be more explicit about how
they're different?
What I see as the defining characteristic of a profile, is that it exists in a
certain directory with a script (etc/profile) & structure to allow an end-user
to activate it.
It lacks some things I associate with the concept of named environments:
- There is afaik no definitive list of profiles on your machine. I know "guix
gc" knows somethings, but "gc --show-roots" doesn't give me useful info here.
If I give names to "named environments" then that implies there's some registry
of names which I can easily query to refer to a specific environment. This is
important for integration with tools where you want to refer to a specific
environment (profile?) by a shorthand name.
- I can easily update environments using my text editor, because they're based
on manifests. I know you can export & import profiles, but the API to update
profiles is basically imperative. Beyond that, it doesn't seem like you can
check a profile into source control, but I'd very much like to check manifests
for named environments into git to share them with people. Maybe this can just
be bridged and we can get some kind of profiles-as-code concept going, as well
as an imperative API for updating manifests (as Sarah Morgensen proposed IIRC
with her "guix env --edit" command)
- Profiles don't seem to have certain desirable features that Guix environments
do, such as pure execution, containerization with or without access to network
or certain parts of the filesystem, etc. Maybe my understanding here is
superficial and you can actually do this with profiles after all?