[PATCH] scripts: pull: Add options for generation management

  • Done
  • quality assurance status badge
Details
4 participants
  • Konrad Hinsen
  • Ludovic Courtès
  • Ricardo Wurmus
  • zimoun
Owner
unassigned
Submitted by
Konrad Hinsen
Severity
normal
K
K
Konrad Hinsen wrote on 18 Sep 2019 09:52
(address . guix-patches@gnu.org)
m1r24em2vj.fsf@fastmail.net
* 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(-)

Toggle diff (150 lines)
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
K
K
Konrad Hinsen wrote on 18 Sep 2019 10:48
(address . 37443@debbugs.gnu.org)
m1ftku3s7h.fsf@khs-macbook.home
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
Z
Z
zimoun wrote on 18 Sep 2019 18:33
Re: [bug#37443] [PATCH] scripts: pull: Add options for generation management
(name . Konrad Hinsen)(address . konrad.hinsen@fastmail.net)(address . 37443@debbugs.gnu.org)
CAJ3okZ2LkRP8v0s30Pj779ZKj2wMs1cT3Ak367sEHSLi8dpdfg@mail.gmail.com
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
K
K
Konrad Hinsen wrote on 18 Sep 2019 22:08
(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 37443@debbugs.gnu.org)
m1a7b14bb9.fsf@khs-macbook.home
Hi Simon,

Toggle quote (8 lines)
> 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
L
L
Ludovic Courtès wrote on 18 Sep 2019 23:07
(name . Konrad Hinsen)(address . konrad.hinsen@fastmail.net)(address . 37443-done@debbugs.gnu.org)
87d0fx71p2.fsf@gnu.org
Hi Konrad,

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

Toggle quote (7 lines)
> * 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!

Toggle quote (18 lines)
> 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’.
Closed
L
L
Ludovic Courtès wrote on 18 Sep 2019 23:18
(name . zimoun)(address . zimon.toutoune@gmail.com)
87y2yl5mma.fsf@gnu.org
Hello zimoun!

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

Toggle quote (8 lines)
> 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’.
K
K
Konrad Hinsen wrote on 19 Sep 2019 08:33
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37443-done@debbugs.gnu.org)
m1muf0aj74.fsf@ordinateur-de-catherine--konrad.home
Hi Ludo,

Toggle quote (2 lines)
> Cool, applied!

Great, thanks!

Toggle quote (3 lines)
> 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.

Toggle quote (3 lines)
> 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.
Closed
L
L
Ludovic Courtès wrote on 19 Sep 2019 10:20
(name . Konrad Hinsen)(address . konrad.hinsen@fastmail.net)(address . 37443-done@debbugs.gnu.org)
87v9toy9wh.fsf@gnu.org
Hello,

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

Toggle quote (7 lines)
>> 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.

Toggle quote (5 lines)
> 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.

Toggle quote (7 lines)
>> 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.

Toggle quote (6 lines)
> 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’.
Closed
Z
Z
zimoun wrote on 19 Sep 2019 11:02
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ0ABEywPw9YvjBYcxM5NYb81W9k559mjrmztTxdNqXNDA@mail.gmail.com
Hi Ludo and Konrad,
Thank you for explaining.
I got the point.

Thanks,
simon
Z
Z
zimoun wrote on 19 Sep 2019 11:41
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ2BQZqc=BHNMg8OLyB2EA2f7rFumY8uqpu7NONam2HCLA@mail.gmail.com
Hi,

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

Toggle quote (10 lines)
> >> 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?


Toggle quote (3 lines)
> > 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".


Toggle quote (3 lines)
> > "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
Closed
K
K
Konrad Hinsen wrote on 19 Sep 2019 12:19
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37443-done@debbugs.gnu.org)
m1tv98wpuf.fsf@fastmail.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (8 lines)
>> 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.
Closed
L
L
Ludovic Courtès wrote on 19 Sep 2019 13:55
(name . Konrad Hinsen)(address . konrad.hinsen@fastmail.net)(address . 37443-done@debbugs.gnu.org)
878sqk33g3.fsf@gnu.org
Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

Toggle quote (22 lines)
> 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”.

Toggle quote (3 lines)
> - 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.)

Toggle quote (6 lines)
> - 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’.
Closed
Z
Z
zimoun wrote on 19 Sep 2019 14:23
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ15Vnuxt64=kWBjwM+0R15z=Q71-+5atULF=S7O_irQjw@mail.gmail.com
On Thu, 19 Sep 2019 at 13:57, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (11 lines)
>
> 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. ;-)

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


Toggle quote (9 lines)
> > - 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
Closed
L
L
Ludovic Courtès wrote on 19 Sep 2019 14:35
(name . zimoun)(address . zimon.toutoune@gmail.com)
874l1831mm.fsf@gnu.org
zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (16 lines)
> 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.
;-)

Toggle quote (2 lines)
> Something nicer should be to have aliases defined by the user.

Yes, that too.

Toggle quote (20 lines)
>> > - 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’.
Closed
K
K
Konrad Hinsen wrote on 19 Sep 2019 15:57
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 37443-done@debbugs.gnu.org)
m1o8zgwfqo.fsf@fastmail.net
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (4 lines)
> 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.

Toggle quote (3 lines)
> 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.

Toggle quote (2 lines)
> Naming is hard!

I have heard that before ;-)

Cheers,
Konrad.
Closed
R
R
Ricardo Wurmus wrote on 19 Sep 2019 19:22
(name . zimoun)(address . zimon.toutoune@gmail.com)
877e64nqtz.fsf@elephly.net
zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (7 lines)
> 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 :)

Toggle quote (2 lines)
> 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/

Toggle quote (9 lines)
>> > 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
Closed
Z
Z
zimoun wrote on 19 Sep 2019 19:27
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ3ekheabJnK5yr7d2KmOt7-_tPXKXGcpwsDUOCx+RZW3w@mail.gmail.com
Hi Ludo,

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

Toggle quote (9 lines)
> >> 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.
> ;-)

Closed
Z
Z
zimoun wrote on 19 Sep 2019 20:17
(name . Ricardo Wurmus)(address . rekado@elephly.net)
CAJ3okZ25MVNFXJ0Q-PR3WJv1kL0f634Qo9+bNLkPVBwJWcPddw@mail.gmail.com
Hi Ricardo,

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

Toggle quote (5 lines)
> 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. :-)


Toggle quote (7 lines)
> > 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? ;-)


Toggle quote (3 lines)
> I’m not convinced this would actually be an improvement. We need to
> avoid sub-command inflation.

Naming is hard. ;-)


All the best,
simon
Closed
K
K
Konrad Hinsen wrote on 19 Sep 2019 20:47
m1lfukw2c1.fsf@khs-macbook.home
zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (11 lines)
> 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)
Closed
L
L
Ludovic Courtès wrote on 19 Sep 2019 21:41
Listing profiles
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87sgosysyp.fsf_-_@gnu.org
Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (5 lines)
> 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’.
Closed
?