Re: “Guix Profiles in Practice”

[Jonathan Frederickson]

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 manifest
Pipfile.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 virtualenv

It 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'.