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

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

[Konrad Hinsen]

* guix/scripts/pull.scm (%options) Add --roll-back, --switch-generation,
--delete-generations
(process-generation-change): New function
(guix-pull): Execute generation management operations

* doc/guix.texi: Document the generation management operations
---
 doc/guix.texi         | 47 +++++++++++++++++++++++++++++++++++++++++--
 guix/scripts/pull.scm | 41 ++++++++++++++++++++++++++++++++++++-
 2 files changed, 85 insertions(+), 3 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 55935b3794..27b58b37e5 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -3673,11 +3673,20 @@ Generation 3	Jun 13 2018 23:31:07	(current)
 @xref{Invoking guix describe, @command{guix describe}}, for other ways to
 describe the current status of Guix.
 
-This @code{~/.config/guix/current} profile works like any other profile
-created by @command{guix package} (@pxref{Invoking guix package}).  That
+This @code{~/.config/guix/current} profile works exactly like the profiles
+created by @command{guix package} (@pxref{Invoking guix package}). That
 is, you can list generations, roll back to the previous
 generation---i.e., the previous Guix---and so on:
 
+@example
+$ guix pull --roll-back
+switched from generation 3 to 2
+$ guix pull --delete-generations=1
+deleting /var/guix/profiles/per-user/charlie/current-guix-1-link
+@end example
+
+You can also use @command{guix package} (@pxref{Invoking guix package})
+to manage the profile by naming it explicitly:
 @example
 $ guix package -p ~/.config/guix/current --roll-back
 switched from generation 3 to 2
@@ -3724,6 +3733,40 @@ is provided, the subset of generations that match @var{pattern}.
 The syntax of @var{pattern} is the same as with @code{guix package
 --list-generations} (@pxref{Invoking guix package}).
 
+@item --roll-back
+@cindex rolling back
+@cindex undoing transactions
+@cindex transactions, undoing
+Roll back to the previous @dfn{generation} of @file{~/.config/guix/current}---i.e.,
+undo the last transaction.
+
+@item --switch-generation=@var{pattern}
+@itemx -S @var{pattern}
+@cindex generations
+Switch to a particular generation defined by @var{pattern}.
+
+@var{pattern} may be either a generation number or a number prefixed
+with ``+'' or ``-''.  The latter means: move forward/backward by a
+specified number of generations.  For example, if you want to return to
+the latest generation after @code{--roll-back}, use
+@code{--switch-generation=+1}.
+
+@item --delete-generations[=@var{pattern}]
+@itemx -d [@var{pattern}]
+When @var{pattern} is omitted, delete all generations except the current
+one.
+
+This command accepts the same patterns as @option{--list-generations}.
+When @var{pattern} is specified, delete the matching generations.  When
+@var{pattern} specifies a duration, generations @emph{older} than the
+specified duration match.  For instance, @code{--delete-generations=1m}
+deletes generations that are more than one month old.
+
+If the current generation matches, it is @emph{not} deleted.
+
+Note that deleting generations prevents rolling back to them.
+Consequently, this command must be used with care.
+
 @xref{Invoking guix describe}, for a way to display information about the
 current generation only.
 
diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index 54bbaddf30..a111f3616d 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -38,7 +38,8 @@
   #:use-module (guix git)
   #:use-module (git)
   #:use-module (gnu packages)
-  #:use-module ((guix scripts package) #:select (build-and-use-profile))
+  #:use-module ((guix scripts package) #:select (build-and-use-profile
+                                                 delete-matching-generations))
   #:use-module ((gnu packages base) #:select (canonical-package))
   #:use-module (gnu packages guile)
   #:use-module ((gnu packages bootstrap)
@@ -91,6 +92,14 @@ Download and deploy the latest version of Guix.\n"))
   (display (G_ "
   -l, --list-generations[=PATTERN]
                          list generations matching PATTERN"))
+  (display (G_ "
+      --roll-back        roll back to the previous generation"))
+  (display (G_ "
+  -d, --delete-generations[=PATTERN]
+                         delete generations matching PATTERN"))
+  (display (G_ "
+  -S, --switch-generation=PATTERN
+                         switch to a generation matching PATTERN"))
   (display (G_ "
   -p, --profile=PROFILE  use PROFILE instead of ~/.config/guix/current"))
   (display (G_ "
@@ -120,6 +129,18 @@ Download and deploy the latest version of Guix.\n"))
                  (lambda (opt name arg result)
                    (cons `(query list-generations ,arg)
                          result)))
+         (option '("roll-back") #f #f
+                 (lambda (opt name arg result)
+                   (cons '(generation roll-back)
+                         result)))
+         (option '(#\S "switch-generation") #t #f
+                 (lambda (opt name arg result)
+                   (cons `(generation switch ,arg)
+                         result)))
+         (option '(#\d "delete-generations") #f #t
+                 (lambda (opt name arg result)
+                   (cons `(generation delete ,arg)
+                         result)))
          (option '(#\N "news") #f #f
                  (lambda (opt name arg result)
                    (cons '(query display-news) result)))
@@ -498,6 +519,22 @@ list of package changes.")))))
      (display-profile-news profile
                            #:current-is-newer? #t))))
 
+(define (process-generation-change opts profile)
+  "Process a request to change the current generation (roll-back, switch, delete)."
+  (unless (assoc-ref opts 'dry-run?)
+    (match (assoc-ref opts 'generation)
+      (('roll-back)
+       (with-store store
+         (roll-back* store profile)))
+      (('switch pattern)
+       (let ((number (relative-generation-spec->number profile pattern)))
+         (if number
+             (switch-to-generation* profile number)
+             (leave (G_ "cannot switch to generation '~a'~%") pattern))))
+      (('delete pattern)
+       (with-store store
+         (delete-matching-generations store profile pattern))))))
+
 (define (channel-list opts)
   "Return the list of channels to use.  If OPTS specify a channel file,
 channels are read from there; otherwise, if ~/.config/guix/channels.scm
@@ -565,6 +602,8 @@ Use '~/.config/guix/channels.scm' instead."))
             (profile  (or (assoc-ref opts 'profile) %current-profile)))
        (cond ((assoc-ref opts 'query)
               (process-query opts profile))
+             ((assoc-ref opts 'generation)
+              (process-generation-change opts profile))
              (else
               (with-store store
                 (ensure-default-profile)
-- 
2.22.1

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

[Konrad Hinsen]

Hi everyone,

let me add an explanation as for why I propose these additions
to guix pull.

I have been working on a tutorial on using Guix for reproducible
research, which will be part of a MOOC on reproducible research.  In
that tutorial, I focus on using "guix environment" with manifest files
for defining computational environemnts. Next, I introduce "guix
describe" and "guix pull -C" to document the version of Guix that has
been used.

At the very end, I use a roll-back to undo the effect of "guix pull -C".
At that point, I had to introduce "guix package" that I never used
before, and also the concept of profiles that I hadn't needed so far
either. All that just for a roll-back!

It is of course nice that internally, the same profile management code
is used for Guix and for installed packages, but I don't think that
users should have to know about that. Moreover, users shouldn't have to
memorize the path of the Guix profile either. With the patch I sent,
Guix generations are entirely managed by "guix pull".

Cheers,
  Konrad

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

[zimoun]

Dear,

Naive question: why not merge the two default profiles in only one
default profile?

`guix pull` uses the default ~/.config/guix/current
`guix package` uses the default ~/.guix-profile

Does it make sense to remove one of them?

And that fixes the issue of UI.


All the best,
simon

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

[Konrad Hinsen]

Hi Simon,

> Naive question: why not merge the two default profiles in only one
> default profile?
>
> `guix pull` uses the default ~/.config/guix/current
> `guix package` uses the default ~/.guix-profile
>
> Does it make sense to remove one of them?

I am not sure if it could be done, but I am rather sure that I wouldn't
want that.

Case study: I want to install one package from a specific Guix commit in
the past:

 - guix pull -C ... creates a new generation
 - guix package install ... creates another new generation

Now I cannot undo the "guix pull" without also removing the package that
I installed from that specific commit!

Cheers,
  Konrad

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

[Ludovic Courtès]

Hi Konrad,

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

> * guix/scripts/pull.scm (%options) Add --roll-back, --switch-generation,
> --delete-generations
> (process-generation-change): New function
> (guix-pull): Execute generation management operations
>
> * doc/guix.texi: Document the generation management operations

Cool, applied!

I think the main reason it hadn’t been done before is laziness, at least
as far as I’m concerned ;-), so I’m glad you took the time to do it!

> I have been working on a tutorial on using Guix for reproducible
> research, which will be part of a MOOC on reproducible research.  In
> that tutorial, I focus on using "guix environment" with manifest files
> for defining computational environemnts. Next, I introduce "guix
> describe" and "guix pull -C" to document the version of Guix that has
> been used.
>
> At the very end, I use a roll-back to undo the effect of "guix pull -C".
> At that point, I had to introduce "guix package" that I never used
> before, and also the concept of profiles that I hadn't needed so far
> either. All that just for a roll-back!
>
> It is of course nice that internally, the same profile management code
> is used for Guix and for installed packages, but I don't think that
> users should have to know about that. Moreover, users shouldn't have to
> memorize the path of the Guix profile either. With the patch I sent,
> Guix generations are entirely managed by "guix pull".

That makes perfect sense to me.

It’s great news that the MOOC will be talking about reproducible
research!

Thank you,
Ludo’.

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

[Ludovic Courtès]

Hello zimoun!

zimoun <zimon.toutoune@gmail.com> skribis:

> Naive question: why not merge the two default profiles in only one
> default profile?
>
> `guix pull` uses the default ~/.config/guix/current
> `guix package` uses the default ~/.guix-profile
>
> Does it make sense to remove one of them?

Nope!  :-)

Technically, it could work of course, since both are just regular
profiles.

The problem is that rolling back your package set would also potentially
roll back the very tool you’re using to roll back.  There could be
problems if, say, the format of ~/.guix-profile/manifest changed, and
you end up with a ‘guix’ that cannot read it because it’s too old,
things like that.

More importantly, I think we really want the tool and the user’s package
set to evolve on different axes.  It’s important to be able to upgrade
or rollback one without touching the other.

Now, it’s true that having two different profiles appears to be hard to
grasp for newcomers, as Ricardo was saying just now on IRC.

HTH!

Ludo’.

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

[Konrad Hinsen]

Hi Ludo,

> Cool, applied!

Great, thanks!

> It’s great news that the MOOC will be talking about reproducible
> research!

That's what it has been doing for a while. The news is that it will
contain a tutorial on using Guix. In parallel with the same task
(defining/communicating/restoring a software environment) using
a more heavyweight toolchain: Debian + debuerreotype + Docker.

> Now, it’s true that having two different profiles appears to be hard
> to grasp for newcomers, as Ricardo was saying just now on IRC.

I suspect that the whole idea of profiles (as distinct from the user
account) is not obvious. If I ever extend my tutorial to include
profiles, I would probably introduce them as persistent environments.

And since I am in criticizing mood, the whole Guix management API
suffers from bad naming. Consider "guix pull -l". What does it pull?  Or
"guix package –-roll-back", which doesn't roll back a package but a
profile. Guix is following the lead of git whose command line API makes
sense only to people who have seen it grow historically.

Konrad.

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

[Ludovic Courtès]

Hello,

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

>> Cool, applied!
>
> Great, thanks!
>
>> It’s great news that the MOOC will be talking about reproducible
>> research!

Uh, I meant: it’s great news that the MOOC on reproducible research will
be talking about Guix.

> That's what it has been doing for a while. The news is that it will
> contain a tutorial on using Guix. In parallel with the same task
> (defining/communicating/restoring a software environment) using
> a more heavyweight toolchain: Debian + debuerreotype + Docker.

I see.

>> Now, it’s true that having two different profiles appears to be hard
>> to grasp for newcomers, as Ricardo was saying just now on IRC.
>
> I suspect that the whole idea of profiles (as distinct from the user
> account) is not obvious. If I ever extend my tutorial to include
> profiles, I would probably introduce them as persistent environments.

Yeah, that’s what they are, so maybe it’s simpler to present profiles as
persistent environments.

> And since I am in criticizing mood, the whole Guix management API
> suffers from bad naming. Consider "guix pull -l". What does it pull?  Or
> "guix package –-roll-back", which doesn't roll back a package but a
> profile. Guix is following the lead of git whose command line API makes
> sense only to people who have seen it grow historically.

What would you suggest?  “guix log”, “guix roll-back”?

Thanks,
Ludo’.

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

[zimoun]

Hi Ludo and Konrad,
Thank you for explaining.
I got the point.

Thanks,
simon

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

[zimoun]

Hi,

On Thu, 19 Sep 2019 at 10:22, Ludovic Courtès <ludo@gnu.org> wrote:

> >> Now, it’s true that having two different profiles appears to be hard
> >> to grasp for newcomers, as Ricardo was saying just now on IRC.
> >
> > I suspect that the whole idea of profiles (as distinct from the user
> > account) is not obvious. If I ever extend my tutorial to include
> > profiles, I would probably introduce them as persistent environments.
>
> Yeah, that’s what they are, so maybe it’s simpler to present profiles as
> persistent environments.

Coming from Conda package manager, it took me some time to understand;
because the Guix terminology was not what I was expecting from the
Conda terminology (in conda "guix environment" does not exist, and
"guix profile" is called environment).

Profile as persistent environment clarifies, IMHO.


Is it possible to list all my own profiles?


> > And since I am in criticizing mood, the whole Guix management API
> > suffers from bad naming. Consider "guix pull -l". What does it pull?  Or

I agree that "guix pull" should be split into:
 - "guix pull" which actually pulls and builds derivations
 - "guix log" which lists, switches or deletes the pull generation

For example "guix log --news" seems better than "guix pull --news".


> > "guix package –-roll-back", which doesn't roll back a package but a
> > profile.

I am not sure to understand this point. What do you mean?

To me, "guix package" manipulates transactions (states).
i.e., "guix package –-roll-back" roll backs a transaction of a profile.

From section 4.1 Features

  The command provides the obvious install, remove, and upgrade
operations.  Each invocation is actually a _transaction_: either the
specified operation succeeds, or nothing happens.  Thus, if the ‘guix
package’ process is terminated during the transaction, or if a power
outage occurs during the transaction, then the user’s profile remains in
its previous state, and remains usable.


Therefore, from my opinion, the UI seems good enough here.


All the best,
simon

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

[Konrad Hinsen]

Ludovic Courtès <ludo@gnu.org> writes:

>> And since I am in criticizing mood, the whole Guix management API
>> suffers from bad naming. Consider "guix pull -l". What does it pull?  Or
>> "guix package –-roll-back", which doesn't roll back a package but a
>> profile. Guix is following the lead of git whose command line API makes
>> sense only to people who have seen it grow historically.
>
> What would you suggest?  “guix log”, “guix roll-back”?

I don't have a detailed and thought-out plan, but here are some ideas:

 - Everything that modifies a profile (the standard package kind) starts
   with "profile":

     guix profile <profile-path> install ...
     guix profile <profile-path> remove ...
     guix profile <profile-path> roll-back

   The <profile-path> could be made optional in some way for working
   on the default profile.

 - The profile-independent operations of "guix package" already have
   nice aliases, e.g. "guix search". So "guix package" could go away.


 - Everything that operates on "guix" (the software, including the
   package definitions) starts with "itself":

     guix itself update  (today's "guix pull")
     guix itself roll-back

Konrad.

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

[Ludovic Courtès]

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>> And since I am in criticizing mood, the whole Guix management API
>>> suffers from bad naming. Consider "guix pull -l". What does it pull?  Or
>>> "guix package –-roll-back", which doesn't roll back a package but a
>>> profile. Guix is following the lead of git whose command line API makes
>>> sense only to people who have seen it grow historically.
>>
>> What would you suggest?  “guix log”, “guix roll-back”?
>
> I don't have a detailed and thought-out plan, but here are some ideas:
>
>  - Everything that modifies a profile (the standard package kind) starts
>    with "profile":
>
>      guix profile <profile-path> install ...
>      guix profile <profile-path> remove ...
>      guix profile <profile-path> roll-back
>
>    The <profile-path> could be made optional in some way for working
>    on the default profile.

OK.  A “guix profile” command has been proposed before.  I think it
makes sense in terms of taxonomy, but I don’t find it pretty in terms of
UI.

Also, now that we finally have “guix install” & co., which is really
what users expect, I feel less of an incentive for a catch-all “guix
profile” command.

Maybe we need more of these aliases, though, like “guix show”.

>  - The profile-independent operations of "guix package" already have
>    nice aliases, e.g. "guix search". So "guix package" could go away.

Yeah.  (In practice ‘guix package’ would have to be kept around, but
it’s OK since all these commands share the same code.)

>  - Everything that operates on "guix" (the software, including the
>    package definitions) starts with "itself":
>
>      guix itself update  (today's "guix pull")
>      guix itself roll-back

It’s a another instance where the categorization you propose makes sense
to me, but as a command I’d have to type, it’s not something I like.

Thanks,
Ludo’.

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

[zimoun]

On Thu, 19 Sep 2019 at 13:57, Ludovic Courtès <ludo@gnu.org> wrote:
>
> Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:
>
> > Ludovic Courtès <ludo@gnu.org> writes:

> Also, now that we finally have “guix install” & co., which is really
> what users expect, I feel less of an incentive for a catch-all “guix
> profile” command.
>
> Maybe we need more of these aliases, though, like “guix show”.

"guix show" would be nice.
But I did not feel a lot of enthusiasm about it. ;-)
https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00264.html

Something nicer should be to have aliases defined by the user.


> >  - Everything that operates on "guix" (the software, including the
> >    package definitions) starts with "itself":
> >
> >      guix itself update  (today's "guix pull")
> >      guix itself roll-back
>
> It’s a another instance where the categorization you propose makes sense
> to me, but as a command I’d have to type, it’s not something I like.

Me neither. :-)

And "guix itself" fixes implicitly the profile to
~/.config/guix/current and maybe people are doing "non-conventional"
stuff as "guix pull -p ~/.guix-profile --list-generations".

"guix pull --list-generations" should be aliased to "guix log"
"guix pull --delete-generations" -> "guix log --delete-generations"
"guix pull --switch-generations" -> "guix log --switch-generations"
"guix pull --news" -> "guix log --news"


All the best,
simon

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

[Ludovic Courtès]

zimoun <zimon.toutoune@gmail.com> skribis:

> On Thu, 19 Sep 2019 at 13:57, Ludovic Courtès <ludo@gnu.org> wrote:
>>
>> Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:
>>
>> > Ludovic Courtès <ludo@gnu.org> writes:
>
>> Also, now that we finally have “guix install” & co., which is really
>> what users expect, I feel less of an incentive for a catch-all “guix
>> profile” command.
>>
>> Maybe we need more of these aliases, though, like “guix show”.
>
> "guix show" would be nice.
> But I did not feel a lot of enthusiasm about it. ;-)
> https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00264.html

I’m enthusiastic every time I type “guix package --show=”, believe me.
;-)

> Something nicer should be to have aliases defined by the user.

Yes, that too.

>> >  - Everything that operates on "guix" (the software, including the
>> >    package definitions) starts with "itself":
>> >
>> >      guix itself update  (today's "guix pull")
>> >      guix itself roll-back
>>
>> It’s a another instance where the categorization you propose makes sense
>> to me, but as a command I’d have to type, it’s not something I like.
>
> Me neither. :-)
>
> And "guix itself" fixes implicitly the profile to
> ~/.config/guix/current and maybe people are doing "non-conventional"
> stuff as "guix pull -p ~/.guix-profile --list-generations".
>
> "guix pull --list-generations" should be aliased to "guix log"
> "guix pull --delete-generations" -> "guix log --delete-generations"
> "guix pull --switch-generations" -> "guix log --switch-generations"
> "guix pull --news" -> "guix log --news"

Though “guix log” is ambiguous: it could mean

  guix pull -l

or:

  guix package -l

or:

  guix build --log-file

Naming is hard!

Ludo’.

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

[Konrad Hinsen]

Ludovic Courtès <ludo@gnu.org> writes:

> OK.  A “guix profile” command has been proposed before.  I think it
> makes sense in terms of taxonomy, but I don’t find it pretty in terms of
> UI.

It's a bit long, but then I don't really install packages so often that
this would bother me. I waste much more time re-reading the man page
every time I use a guix subcommand I haven't used in a while.

> It’s a another instance where the categorization you propose makes sense
> to me, but as a command I’d have to type, it’s not something I like.

Same comment. I really like Guix, but that doesn't mean I spend much
time typing Guix commands. It's a rare event.

My priorities in command API design for Guix would be
 1. Clear: when I type a command, I want to be sure what exactly it does.
 2. Memorizable: minimize the need to re-read the documentation.
 3. Error tolerant: a one-letter typo or a forgotten argument shouldn't
    lead to some completely different action.

Typing efficiency doesn't even make it to the list.

> Naming is hard!

I have heard that before ;-)

Cheers,
  Konrad.

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

[Ricardo Wurmus]

zimoun <zimon.toutoune@gmail.com> writes:

> Coming from Conda package manager, it took me some time to understand;
> because the Guix terminology was not what I was expecting from the
> Conda terminology (in conda "guix environment" does not exist, and
> "guix profile" is called environment).
>
> Profile as persistent environment clarifies, IMHO.

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

> 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/

>> > And since I am in criticizing mood, the whole Guix management API
>> > suffers from bad naming. Consider "guix pull -l". What does it pull?  Or
>
> I agree that "guix pull" should be split into:
>  - "guix pull" which actually pulls and builds derivations
>  - "guix log" which lists, switches or deletes the pull generation
>
> For example "guix log --news" seems better than "guix pull --news".

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

--
Ricardo

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

[zimoun]

Hi Ludo,

On Thu, 19 Sep 2019 at 14:35, Ludovic Courtès <ludo@gnu.org> wrote:

> >> Maybe we need more of these aliases, though, like “guix show”.
> >
> > "guix show" would be nice.
> > But I did not feel a lot of enthusiasm about it. ;-)
> > https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00264.html
>
> I’m enthusiastic every time I type “guix package --show=”, believe me.
> ;-)

Done here https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37462 :-)


All the best,
simon

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

[zimoun]

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

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

[Konrad Hinsen]

zimoun <zimon.toutoune@gmail.com> writes:

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

Also: how do you distinguish between creating an environment from a
manifest and rebuilding a profile from a manifest?

Konrad (manifest addict)

[bug#37443] Listing profiles

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> Not with a simple command, but Guix does keep links to profiles.  Take a
> look here:
>
>     /var/guix/gcroots/profiles/per-user/zimoun/

That doesn’t show profiles that live in different locations, though.

“guix gc --list-roots” gets closer to that, but not quite.  I’ll try to
come up with a patch to add “guix package --list-profiles”.

Thanks,
Ludo’.