diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/guix-cookbook.texi | 39 |
1 files changed, 16 insertions, 23 deletions
diff --git a/doc/guix-cookbook.texi b/doc/guix-cookbook.texi index 712c131a51..1259f6aac7 100644 --- a/doc/guix-cookbook.texi +++ b/doc/guix-cookbook.texi @@ -3714,7 +3714,7 @@ reference. @section Guix Profiles in Practice Guix provides a very useful feature that may be quite foreign to newcomers: -@emph{profiles}. They are a way to group package installations together and all users +@dfn{profiles}. They are a way to group package installations together and all users on the same system are free to use as many profiles as they want. Whether you're a developer or not, you may find that multiple profiles bring you @@ -3722,6 +3722,16 @@ great power and flexibility. While they shift the paradigm somewhat compared to @emph{traditional package managers}, they are very convenient to use once you've understood how to set them up. +@quotation Note +This section is an opinionated guide on the use of multiple profiles. +It predates @command{guix shell} and its fast profile cache +(@pxref{Invoking guix shell,,, guix, GNU Guix Reference Manual}). + +In many cases, you may find that using @command{guix shell} to set up +the environment you need, when you need it, is less work that +maintaining a dedicated profile. Your call! +@end quotation + If you are familiar with Python's @samp{virtualenv}, you can think of a profile as a kind of universal @samp{virtualenv} that can hold any kind of software whatsoever, not just Python software. Furthermore, profiles are self-sufficient: they capture @@ -4034,29 +4044,12 @@ profiles, they are not strictly equivalent: profiles have the side effect that they ``pin'' packages in the store, which prevents them from being garbage-collected (@pxref{Invoking guix gc,,, guix, GNU Guix Reference Manual}) and ensures that they will still be available at any point in -the future. - -Let's take an example: - -@enumerate -@item -We have an environment for hacking on a project for which there isn't a Guix -package yet. We build the environment using a manifest, and then run @code{guix - environment -m manifest.scm}. So far so good. - -@item -Many weeks pass and we have run a couple of @code{guix pull} in the mean time. -Maybe a dependency from our manifest has been updated; or we may have run -@code{guix gc} and some packages needed by our manifest have been -garbage-collected. - -@item -Eventually, we set to work on that project again, so we run @code{guix shell - -m manifest.scm}. But now we have to wait for Guix to build and install -stuff! -@end enumerate +the future. The @command{guix shell} command also protects +recently-used profiles from garbage collection; profiles that have not +been used for a while may be garbage-collected though, along with the +packages they refer to. -Ideally, we could spare the rebuild time. And indeed we can, all we need is to +To be 100% sure that a given profile will never be collected, install the manifest to a profile and use @code{GUIX_PROFILE=/the/profile; . "$GUIX_PROFILE"/etc/profile} as explained above: this guarantees that our hacking environment will be available at all times. |