[bug#39258] [PATCH v4 0/3] Faster cache generation (similar as v3)

[Ludovic Courtès]

Hi,

zimoun <address@hidden> skribis:

> On Sun, 3 May 2020 at 18:43, Ludovic Courtès <address@hidden> wrote:
>
>> > Therefore the cache '/lib/guix/package.cache' contains more
>> > information.
>>
>> This breaks the binary interface, so we’ll have to analyze the impact of
>> such a change and devise a strategy.
>
> Interface between what and what?

Guix revision N creates a cache that will be read by revision N+1, upon
‘guix pull’ completion.

> Note that I have read your comment in v3 2/3 but I did not understand it. 
> Sorry.
>
> I realize the other cache also has that problem, but it would be nice to
> add a version tag to the cache.  Basically emit something like:
>
>   (package-metadata-cache (version 0) VECTOR …)
>
> instead of just:
>
>   (VECTOR …)

Yes, it would be better.

> For example, 'supported-systems' is saved as a list of strings,
> whereas 'license' is expanded as 3 strings without be packed in a list
> of strings.  From my point of view, it is inconsistent and I do not
> know what is the best (readibility, startup time, etc.).

I guess both ‘license’ and ‘supported-systems’ should be list of
strings.  It doesn’t really have an impact on startup time (I thought
you were suggesting storing the cache as an sexp instead of an object
file.)

>> Something that must be done explicitly doesn’t seem great to me.  As a
>> user, I’d rather not think about search indexes and all.  But I don’t
>> know, maybe if it happened automatically on the first ‘guix search’
>> invocation that’d be fine.
>
> I do not think it is an option to build the BM25 the first time "guix
> search" is called.  Back-to-envelop estimation, it needs ~25 seconds
> to Xapian* to do so.
>
> From my point of view, two options:
>  a) "guix pull" does this extra ~25 seconds (compared to 10 seconds to
> build the v4 cache)
>  b) the user manually build the index (I agree it is awkward!)
>
> Well, the first question is to evaluate if it is worth -- I am using
> the v2 version based on Xapian to have an idea.  Please if you have
> suggestions about query (terms an user could type) and results
> (packages an user could expect), there are welcome.

Yeah, dunno.  Maybe an option would be to create the index in such a way
that it is substitutable.


[...]

> Yes, it was already your suggestion in v3 3/3.  Do you suggest to
> refactor 'package->recutils'? For example,
>
> (define* (package->recutils name version
>                             ... all-the-other-fields ...
>                             port #:optional (width (%text-width))
>                             #:key
>                             (hyperlinks? (supports-hyperlinks? port))
>                             (extra-fields '()))

Yes.

>> >  4. Impolite '@@' is used to access the private license construction.
>>
>> (guix licenses) could provide a ‘string->license’ procedure.
>
> Well, do you suggest:
>
>     (define (string->license name) (license name #f #f))

No; rather, it would look up the license in a dictionary and return the
corresponding object or #f if it’s not a known license.

Thanks,
Ludo’.