Hi!

While playing with multiple profiles and manifests and discussing with
a couple of people in the community, I collected a number of usability
issues with Guix when it comes to managing multiple profiles and dealing
with manifests.

Ideas for new features, more or less from most important to least
important:

- Activate a profile with =guix activate /path/to/profile=.
  Right now, the most appropriate way to activate a profile is

--8<---------------cut here---------------start------------->8---
GUIX_PROFILE="$profile" ; . "$profile"/etc/profile
--8<---------------cut here---------------end--------------->8---

  But this is flawed: it exposes implementation details plus it fails to
  set important variables like MANPATH or INFOPATH if man-db /
  info-reader or not installed in the said profile.  See /etc/profile
  for the full list of what =guix activate= should do.

- The inverse command, =guix deactivate /path/to/profile=.
  This can be useful to deactivate a profile that was activated during login.

- All commands that accept manifests should be able to compose manifests
  by passing multiple =--manifest FILE= options.
  
- Auto-update manifests when calling =guix package -m manifest.scm -i
  foo -r bar=.  This would make users more inclined to user manifests
  even for "quick and dirty" installs.  See next point.

  This means we need to edit the code, but that's doable since the last
  form of manifest.scm must evaluate to a manifest.  So we could proceed
  as follows:

  + If the last form is a spec, edit the list directly.
  + If not, then wrap the last form in the appropriate `manifest-add' /
  `manifest-remove' calls, e.g.

--8<---------------cut here---------------start------------->8---
(manifest-add "foo"
  (manifest-delete "bar"
    my-manifest))
--8<---------------cut here---------------end--------------->8---

- Use a default manifest by default with =guix install= and =guix
  remove=.  This way would basically get rid of "ad-hoc" profiles which
  has so many flaws (non-reproducible, non-trackable, etc.).

Last, one that's at the Scheme level:

- A Scheme function to create a manifest for the necessary inputs of a
  package, like =guix environment PACKAGE= does.  (Maybe it's already possible?)


Thoughts?

-- 
Pierre Neidhardt
https://ambrevar.xyz/