"Thompson, David" <[email protected]> writes:
This has come up periodically over the years. I've wanted this
for a decade
at this point.
Hi David,
Thanks for the very helpful reply. I do not know whether it is
encouraging or discouraging that you have wanted this for so long.
We shouldn't be referring to file names here. These should be
lists of
channel and manifest objects, respectively.
Good point on not storing filenames in the record. The direction
we are heading now is that <environment> holds a single resolved
<manifest> object (and later, if/when we add channels/time-machine
layering, it would similarly hold channel objects rather than
"channels.scm" strings). Filenames remain just one input mechanism
at the CLI layer.
Being able to save state and resume later, even if you did a
'guix pull' in
between, is a good thing to have. However, I don't think this is
an
ergonomic way to do it. Running 'guix session' should just load
a saved
session automatically, if there is one. Let the user run a
command to
update when they want to do that.
Resuming saved state automatically makes sense. Based on Ludo's
suggestion we are thinking of keeping <environment> strictly about
“how to run”, and treating “saved/resumable state + update” as a
higher-level layer on top.
Services. Imagine you are developing a web application. You'd
probably want
'guix session' to at least launch a database server. This would
be
accomplished by starting a Shepherd daemon with a (perhaps
containerized)
database service that keeps all of its state local to the
project root
directory. The unfortunate thing here is that neither system nor
home
services are the right fit. There would need to be a new service
layer for
this tool. This is something I could rant about, but I will
refrain. :)
I like the “docker compose but Guix/Shepherd” idea. I’m hoping we
figure out <environment> + environment.scm first, and then iterate
toward state/resume and (eventually) project-local services.
It's a great initiative! I'd be an enthusiastic early adopter.
- Dave
If you have any pointers from your old prototypes, or even rough
notes, they could be very useful. Thanks!
