Re: PRELIMINARY: [PATCH] guix package: Add '--list-generations'.

[ludo@gnu.org (Ludovic Courtès)]

Nikita Karetnikov <nikita@karetnikov.org> skribis:

>> Not sure what you mean by “two record sets”.
>
> “You can have two record sets: one for generations, one for
> packages.” [1]

Ah so I was referring to recutils record sets (I thought you were
talking about SRFI-9 records or something.)  So what’s the question?
:-)

>>> Why do you suggest to put ‘string->duration’ into (guix ui)?
>
>> Because it’s a user-interface function.
>
> Done.  However, I think it would be better to write more generic
> procedures if we want to place them in separate modules, so they can be
> reused.  (I can replace the current version with a more generic one if
> you want.)

Well, ‘string->duration’ is just as generic as ‘string->number’.

However I agree ‘string->generation’ could remain internal to
(guix scripts package).  No big deal though.

> I’m attaching the patch.  Please don’t push it yet.  I’ve just found a
> bug.  On my machine, ‘guix package -p test -l 2d’ and ‘guix package -p
> test -l’ should return the same set of generations, but the fourth
> generation is shown twice in the former case.

OK.

> Other issues:
>
> 1. ‘false-if-exception’ in ‘generation-ctime’.
>
> 2. A race condition (marked with XXX).
>
> 3. ‘guix package -l -p test’ returns ‘guix package: error: test:
>    extraneous argument’.  (However, the same happens with ‘-I’.)
>
> 4. There must be a better way to write the test in
>    ‘tests/guix-package.sh’.

[...]

> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -606,6 +606,42 @@ library are installed in the profile, then @code{--search-paths} will
>  suggest setting these variables to @code{@var{profile}/include} and
>  @code{@var{profile}/lib}, respectively.
>  
> +@item --list-generations[=@var{regexp}]
> +@itemx -l [@var{regexp}]

s/regexp/pattern/

> +Return a list of generations along with their creation dates.
> +
> +For each installed package, print the following items, separated by
> +tabs: the name of a package, its version string, the part of the package
> +that is installed (@pxref{Packages with Multiple Outputs}), and the
> +location of this package in the store.
> +
> +When @var{regexp} is used, the command returns only matching
> +generations.  Valid patterns include:
> +
> +@itemize
> +@item @emph{Integers and comma-separated integers}.  Both patterns will simply
> +return the corresponding generations.  For instance,
> +@code{--list-generations=1} will return the first one.

I’d use @table rather than @itemize.

Wording: a pattern doesn’t “return” anything, so perhaps:

  These patterns denote generation numbers.

> +If you pass @code{--list-generations=1,8,2}, the command will return
> +three generations in the specified order.  Neither spaces nor trailing
> +commas are allowed.

s/If you pass/Passing/
s/will return/specifies/

> @@ -441,6 +502,9 @@ Install, remove, or upgrade PACKAGES in a single transaction.\n"))
>        --roll-back        roll back to the previous generation"))
>    (display (_ "
>        --search-paths     display needed environment variable definitions"))
> +  (display (_ "
> +  -l  --list-generations[=REGEXP]
> +                         list generations matching REGEXP"))

Should be “-l, --list-generations”, with a comma.
s/REGEXP/PATTERN/

> --- a/tests/guix-package.sh
> +++ b/tests/guix-package.sh
> @@ -81,6 +81,10 @@ then
>          "name: hello"
>      test "`guix package -s "n0t4r341p4ck4g3"`" = ""
>  
> +    # List generations.
> +    test "`guix package -p "$profile" -l | cut -f1 | grep guile | head -n1`" \
> +        = "  guile-bootstrap"

That’s OK.  You could also grep the string “generation 1” (assuming
we’re running in the C locale, dunno if it’s the case.)

> +(test-equal "infinite end range"

s/infinite/indefinite/

Looks like this is ready to get in!

Ludo’.