Re: New ‘--list-generations’ and ‘--delete-generations’ options

[Ludovic Courtès]

Nikita Karetnikov <address@hidden> skribis:

>> Cool.  The diff looks great...  but it lacks tests.
>
> Yes, I wanted to finish the recutils part first.

I think it’s reasonable to have a first milestone without recutils
output.

> I’ve been thinking about that, and I don’t like that we’d have to use
> two record sets.  It’d be necessary to post-process the output nearly
> every time.  Then why bother?  We can already filter the output using
> regexps.

Not sure what you mean by “two record sets”.

I see two use cases: one where you just want human-friendly output, for
when one is glancing at the available generations, and one that is more
amenable to Unix pipelines for post-processing.  Recutils output is for
the latter case.

> I still think that someone may benefit from the recutils format.  So
> let’s allow the ‘recutils’ argument that would list all generations in
> that format [1] and use the following format [2] for everything else:
>
>   generation 1     Dec 16 2013
>     guile    2.0.7 out,debug    gnu/packages/guile.scm
>     hello    2.8   out          gnu/packages/base.scm
>
>   generation 2     May 7 2013
>     guile    2.0.9 out          gnu/packages/guile.scm
>
> Is it OK?

Yes.

> Should it point to the store instead of (gnu packages …)?

Yes, I think so.

> Also, why did you propose to use ‘object->fields’?  Should I create an
> SRFI-9 record representing the recutils fields?

‘object->fields’ is just a convenient way to serialize an object in
recutils format.

So no, you don’t need a new record type for the recutils field.  Instead
you would just serialize the objects that represent a profile/manifest
using that (currently there’s no distinct record type for those, but the
idea is the same.)

>> What you could do is add the test cases you already have to
>> tests/profile.scm, say (or tests/ui.scm for ‘string->duration’, and then
>> put that one in (guix ui)?), along with a simple test in
>> tests/guix-package.sh.
>
> Why do you suggest to put ‘string->duration’ into (guix ui)?

Because it’s a user-interface function.

> I think we should try to write all tests in Scheme, so we could switch
> to property-based testing at some point (see [3], for instance).

We still want to test the command-line user interface too.  That’s why
there’s tests/packages.scm *and* tests/guix-package.sh, for instance.

Besides, I’m all for QuickCheck-style tests, there just wasn’t any
ready-to-use lib for Guile at the time (I think Ian Price has
written/ported one in the meantime, though.)

>>> (Is it necessary to mention that ‘maybe-comma-separated-integers’ accepts
>>> something like ‘1,2,3,’ or ‘1,,,2’.  Or should I change the function?)
>
>> That’s OK.
>
> Hmmm, it feels sloppy, so I’ve changed the function:

Even better.  :-)

>>> +(define (string->generations str)
>>> +  "Return a list of generations matching a pattern in STR.  This function
>
>> Return *the* list of...
>
> Done.
>
> I never know which article should be used in such cases; the docstring
> talks about it for the first time…  On the other hand, it talks about a
> particular object.  How do you distinguish these cases?

Here we’re using Scheme lists to represent a set, and there can be only
one set of generations matching the given pattern; that’s why I
suggested ‘the’ instead of ‘a’.

In general I like to remove any ambiguity, and using ‘a’ is often a
source of ambiguity.

>>> guix package: error: build failed: getting attributes of path 
>>> `/nix/store/fcwh19ljibqjfx0c3cwnwcc7p31aq227-glibc-2.17-locales': No such 
>>> file or directory
>
>> Arf, what have you dooooone?
>
> I don’t knooooow!
>
>> Maybe you can try ‘nix-store --verify’
>
> I installed Nix 1.5.3. and ran the command:
>
> error: setting synchronous mode: unable to open database file

Problem with permissions on the SQLite database, I guess.

Thanks,
Ludo’.