Hi, "Thompson, David" <dthomps...@worcester.edu> 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’.
