|
From: | Jonathan Frederickson |
Subject: | Re: “Guix Profiles in Practice” |
Date: | Fri, 25 Oct 2019 20:34:04 -0400 |
User-agent: | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Thunderbird/70.0 |
On 10/25/19 12:36 PM, Thompson, David wrote
'guix environment' is a very composable command, and it's not clear to me how I would add the stuff I want onto it and it's even less clear if it's a good idea. Probably not. So, I wonder if maybe a new subcommand, say 'guix develop', could address this common development use-case while allowing 'guix environment' to continue being the swiss army knife that it is. Some simple naming conventions could make this tool "just work." Running 'guix develop' would check for a profile symlink with some canonical name, for example '.guix-develop-profile'. If it exists, it applies the environment variables and spawns a subshell. If it doesn't exist, it looks for a 'develop.scm' file (canonical name TBD), builds the profile, symlinks it to '.guix-develop-profile', and then does the prior steps. The tool would provide a mechanism to update, etc. and it could even be expanded later to spawn services like databases.
I love this idea, though I'd like to expand upon that a bit. There's another tool in the Python world that does something similar called Pipenv. The gist of it is:
Pipfile: analogous to a Guix manifestPipfile.lock: analogous to a Guix manifest + channel spec (this file contains precisely specified dependency versions) ~/.local/share/virtualenvs/<venv name>: Generated virtualenvs (analogous to a Guix profile, of course)
You work with these as follows: $ pipenv install^ creates a virtualenv with packages from Pipfile.lock (if it exists) otherwise creates a virtualenv with packages from Pipfile and (by default) creates Pipfile.lock
$ pipenv lock ^ resolves dependencies for packages in Pipfile and (re)creates Pipfile.lock $ pipenv shell ^ spawns a subshell in the project's virtualenvIt occurs to me that you could nicely replicate this behavior in Guix by doing much the same thing; have a convenience command that reads a manifest with a well-known filename, creates profiles in a well-known location, and generates a channel spec (probably the current version of Guix the first time it's run). The end result is that a user could clone a project with both a manifest and channel spec and end up in the same environment by just running 'guix develop'.
[Prev in Thread] | Current Thread | [Next in Thread] |