[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Blog/Cookbook?] On multiple Guix profiles and manifests
From: |
Todor Kondić |
Subject: |
Re: [Blog/Cookbook?] On multiple Guix profiles and manifests |
Date: |
Mon, 07 Oct 2019 09:56:59 +0000 |
On Saturday, 5 October 2019 12:55, Pierre Neidhardt <address@hidden> wrote:
> Hi!
>
> While the documentation refers to profiles and manifests, it does not tell
> much
> of the use cases and the practical benefits.
>
> For users coming from non-functional package managers, it's not really obvious
> why we would need profiles.
>
> Regarding manifest, I suppose some people might find them annoying to use
> because updating/adding just 1 program means rebuilding the whole profile,
> which
> after a Guix pull can be somewhat lengthy.
>
> So what about writing a blog article / cookbook chapter to explain why
> profiles and manifests are truly awesome indeed? (Unless this has
> already been done and I missed it?)
>
> A quick 'n' dirty outline:
>
> A manifest can be slow to install if it's too big. But Guix supports profile,
> which are perfect to break down manifests into multiple sets of semantically
> connected packages.
>
> Example profiles:
>
> - Emacs.
> - TeXlive (this one can be really useful when you need to install just one
> package for the next document you've received over email).
>
> - Your favourite programming language libraries.
> - The dependencies of a project you are working on
> - Games :p
>
> We can create a manifest per profile and install them this way:
>
> guix package --manifest=/path/to/guix-dev-manifest.scm
> --profile=$HOME/.guix-extra-profiles/dev/dev
>
> Placing all your profiles in a single folder, with each profile getting
> its own
> subfolder is somewhat cleaner, plus it's obvious to "loop over profiles"
> from
> any programming language (e.g. a shell script) by
> simply looping over the sub-directories of .guix-extra-profiles.
>
> Note that it's also possible to loop over the output of `guix package
> --list-profiles` although you'll probably have to filter out
> `~/.config/guix/current`.
>
> To "enable" all profiles on login, add this to your .bash_profile (or
> .profile
> if you don't use bash):
>
> #+begin_src sh
> for i in ~/.guix-extra-profiles/*; do
> profile=$i/$(basename "$i")
> if [ -f "$profile"/etc/profile ]; then
> GUIX_PROFILE="$profile" ; . "$profile"/etc/profile
> fi
> unset profile
> done
> #+end_src
>
> I like to keep the default ~/.guix-profile manifest-less for trash-away
> packages
> that I would just use for a couple of days.
> This way it's easy to just run
>
> guix install FOO
> guix upgrade BAR
>
> and I don't have to specify the profile.
>
> Other benefits of manifests:
>
> - No need to generate or maintain a manifest from an ad-hoc profile.
> - "guix package -u" will always suggest to update some packages of those
> have
> propagated inputs. Guix manifests avoid this problem.
>
> - "guix package -u [packages...]" may report conflicts which are annoying to
> resolve manually. Manifests avoid this problem altogether.
>
> Other benefits of multiple profiles
>
> - It's easy to toggle a specific profile on/off.
> - When a profile is off, it's easy to enable it for an individual shell
> without
> "polluting" the rest of the user session:
>
> #+begin_src sh
> GUIX_PROFILE="$profile" ; . "$profile"/etc/profile
> #+end_src
>
> Happy to hear about your feedback!
>
> Cheers!
>
> --
> Pierre Neidhardt
> https://ambrevar.xyz/
>
What is the advantage of having different profiles to just defining different
top-level packages propagating all programs and libraries one needs and placing
them in a custom channel? My feeling is, defining a package is cleaner than
manifests+profiles, because it does not involve creating yet another shell
program that needs to be sourced.