[bug#37443] [PATCH] scripts: pull: Add options for generation management

[zimoun <zimon.toutoune@gmail.com>]

Hi Ricardo,

On Thu, 19 Sep 2019 at 19:23, Ricardo Wurmus <rekado@elephly.net> wrote:

> Instead of providing a “guix profile” command, another option would be
> to merge “guix package” and “guix environment” to just “guix
> env[ironment]”.  We could finally get rid of “guix environment
> --ad-hoc” while we’re at it :)

Thank you to feed my thoughts.

Your propose something like:

guix package -i foo
  -> guix env -i foo
guix environment guile --ad-hoc emacs --pure
  -> guix env --deps=guile -i emacs --pure

But what becomes:
 guix environment --ad-hoc foo
  -> guix env -i foo --name-it ?

I agree that this merge seems to ease the introduction of Guix
concepts by smoothing the gap with the other package managers. Kind
of. :-)


> > Is it possible to list all my own profiles?
>
> Not with a simple command, but Guix does keep links to profiles.  Take a
> look here:
>
>     /var/guix/gcroots/profiles/per-user/zimoun/

Thank you for explaining.

Hum? I have profiles which are not listed there.
I only see current-guix and guix-profile (and their generations).


Well, with the package manager Conda, there is an "useful" command:
 conda info --envs
which list all the "conda environments" (i.e., "guix profile") created
with "conda create -n foo" (i.e., "guix package -p foo").
(it is ease in conda world because the user cannot create the
environment/profile wherever they wants)

Because some weeks/month can separate two sessions of work in one
particular profile, in general I do not remember its name. And because
you can create the profile wherever you want, I sometimes spend some
time to reach this profile. It is annoying. :-)
So, the solution that I use is to create one folder containing all my
profiles or to put in the project folder. It is good practise, I
guess. But discipline is hard. ;-)

I would find more convenient to be able to list them.
(bikeshedding? ;-)


> I’m not convinced this would actually be an improvement.  We need to
> avoid sub-command inflation.

Naming is hard. ;-)


All the best,
simon