Pierre Neidhardt <mail@ambrevar.xyz> writes:

>> I think the Guix Data Service is a good fit since it knows about
>> packages, derivations, commits, and how they map to each other.  :-)  It
>> could download nars and do the equivalent of ‘guix archive -t’ to get
>> the list of file names.
>
> Are you suggesting that guix "filesearch" polls a specific instance of
> the Guix Data Service (e.g. data.guix.gnu.org) to download the file
> index fro the current Guix revision?

So, to elaborate a bit more on the architecture I've had in mind for
dealing with the actual nars…

I see the scope of the Guix Data Service extending as far as what nars
are available for outputs, and what outputs are associated with each
revision, but I don't think it should store the actual nar files.

What you could have is another service, which subscribes to the Guix
Data Service to find out about new revisions and nars (from build
servers). When this new service finds out about Guix revisions, it would
ask this Guix Data Service for all the outputs, and store this away in a
database. When it finds out about nars, it would download them, and
maybe extract out the list of files.

I think this setup would allow this new service to construct a file
containing information about all files in all the outputs for a
revision, which it has nars available for. This file could then be
downloaded, and searched through when you want to find which output
contains a file.

> What if the file index for a specific Guix commit (e.g. a very recent
> one) is not yet available?  I suggest we fall back to the first older
> index that's available, with a warning.  Thoughts?

Sounds sensible.