Re: “Guix Profiles in Practice”

[Ludovic Courtès]

Hi,

"Thompson, David" <address@hidden> skribis:

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

That sounds like a good idea.  ‘guix develop’ could keep the profiles it
manages under ~/.cache/guix.

Now, this would be very much stateful: you can’t tell in advance whether
you’re going to build a new profile based on the current Guix, or
whether you’re going to reuse a previously cached profile that could be
arbitrarily old.  That doesn’t sound great.

Perhaps we should focus on improving the performance of ‘guix
environment’ first and foremost?

Thanks,
Ludo’.