Hi, Peter Polidoro <[email protected]> skribis:
> Ludovic Courtès <[email protected]> writes: >> One thing that’s been discussed before is having (guix scripts >> shell) >> expose an <environment> structure to represent everything that >> manifests >> don’t represent: pure or container, shared directories, preserved >> environment variables, etc. That could be the first step. > > Oh interesting, so a session, or whatever name you prefer, would just > be > a channels file, one or more manifests, and an <environment>. Yes. Or maybe <environment> could include a manifest. > That makes a nice clean separation between what goes in the profile, > manifests, and how they are run, the environment. > > Do you have any links to previous discussions about the desired > environment structure? Is anyone working on that now? I can’t find it sorry (searching for “environment” in my mail archive isn’t helpful :-)). > So the guix shell CLI would remain identical, but (guix scripts shell) > would need some refactoring to gather the command line flags and > parameters into an environment structure? Then perhaps you would want > a > small API as a hook for other Guile code to drive guix shell behavior > programmatically? The first step would be to define an <environment> record to describe all these aspects we talked about. Then ‘guix shell’ could have an option to load a file that returns an <environment> and maybe it could by default load, say, ‘environment.scm’ if it finds it (similar to how that works with ‘manifest.scm’ and ‘guix.scm’). WDYT? Ludo’.
