That's the beauty of functional package management: no global state is modified. Whatever Guix does is restricted to its own namespace, e.g. the /gnu directory. Every package that is built or installed ends up there and is completely isolated from the rest of the system.
To actually use the software you use a link to a profile (which is located in the "local state" directory of Guix).
You can install packages into separate profiles with Guix:
guix package -p /path/to/dev/profile -i postgresql
Or you can just run a shell in a volatile environment as specified in `myapp.scm` guix environment -l myapp.scm
To exit this environment, just exit the shell.In summary: it can already be used just like you want, but it's much less verbose :)
For your PostgreSQL example, you'd still need to do things like initialize the DB cluster and start the daemon on your own (the GuixSD distro has a system service for this[1]), but to spawn a shell with the postgres daemon and client programs available you would run:
guix environment --ad-hoc postgresql
Exiting the sub-shell would do essentially what you had in mind with 'guix deactivate': Make postgresql available for garbage collection (via 'guix gc') if/when nothing else is using it.[0] https://gnu.org/software/guix/manual/html_node/Binary-Instal...
[1] https://gnu.org/software/guix/manual/html_node/Database-Serv...
I'm installing it and see how it goes, thanks.
guix package -p $(pwd)/.guix-profile -i what ever you want
Programmes in this profile can then be executed like so: ./.guix-profile/bin/what
But that's not necessary when you could just use `guix environment` and enter a shell where everything is already hooked up.
I'm not sure I want to install guix on my main Archlinux box, as I don't want conflicts with the existing libraries and applications, but I would very much play with it if it were possible to do something like this:
This would be a killer feature for me and I would ditch virtualenv, pip, npm, perhaps Docker in a heartbeat.