Re: Profiles/manifests-related command line interface enhancements

["Ludovic Courtès" <ludo@gnu.org>]

Hi Pierre!

Thanks for looking into this!  (And sorry for being late to the party. :-))

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> - Activate a profile with =guix activate /path/to/profile=.
>   Right now, the most appropriate way to activate a profile is
>
> GUIX_PROFILE="$profile" ; . "$profile"/etc/profile
>

Another way is:

  eval `guix package --search-paths=prefix`

or similar.

Another one is:

  guix environment …

>   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 MANPATH issue is orthogonal so I don’t think we should bring it up
in this context.  See <https://issues.guix.gnu.org/issue/22138> for
context.

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

The activate/deactivate is similar to what CONDA does (from what I
understand; I’ve never used it) and similar to “module load” with
<http://modules.sourceforge.net/>.  It’s a nice pattern, though I think
it’s easy to lose track of what’s activated and what not, and it’s
tricky to define ‘deactivate’ correctly.

Regarding environment variables, “module” uses a trick where (roughly)
“module” itself is a shell function, such that it can adjust the
environment variables of the shell that invokes it.  We could do
something similar, though that would be limited to POSIX shells I guess.

> - All commands that accept manifests should be able to compose manifests
>   by passing multiple =--manifest FILE= options.

Do you have a use case?  :-)

Sounds like something quite easy to do but I’ve never heard anyone
request it before so I’m curious.

> - 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.
>
> (manifest-add "foo"
>   (manifest-delete "bar"
>     my-manifest))

Could be fun, but… needs more thought.

> - 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.).

Ambitious!

Note that “ad-hoc” profiles (imperatively-managed profiles) contain
provenance info in their ‘manifest’ file, so it’s not black and white.

> 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?)

Like ‘specifications->manifest’?

I think we should isolate different actionable items from this list and
work on them independently, to the extent possible.

Note that another option is to overhaul ‘guix environment’ like David
proposed a while back:

  https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html

I very much like those ideas, and I like the idea of making ‘guix
environment’ central (as opposed to offering more ways to manage
environments.)  It’s not completely the same goals as what you’re
looking for, but there’s some overlap.  Food for thought!

Thanks,
Ludo’.