Re: [swh-devel] Call for public review - SWH Nix/GNU Guix stack
Hello, > Is that because the changes you describe were done after the staging > data was loaded or is it a bug? Our staging instance inherits its append-only property from our main archive. In the staging case (for "prototypes", soon-to-be-deployed new feature or so), that makes it hard to see through the "old bug" noise. It's old origins that were ingested initially with a first version of the lister (which got iteratively fixed). @anlambert made a pass this week in docker (from scratch) to check (thx ;) > Excellent! I believe this addresses a problem we recently reported > regarding tarballs published with our own content-addressed URLs, which > look like: > > > https://bordeaux.guix.gnu.org/file/BiocNeighbors_1.20.0.tar.gz/sha256/0a5wg099fgwjbzd6r3mr4l02rcmjqlkdcz1w97qzwx1mir41fmas As a result, he actually enhanced the listing so the urls mentioned earlier ^ is treated correctly out of the data in the url. (@me That needs a bump in deployment [for next week]) Early on, I was referring to another heuristic using a HEAD query to parse header informations [if any]. As that specific url does not provide any, so it passed through. Note: cc-ed jul...@malka.sh instead of commun...@nixos.org (as asked in the thread) Cheers, -- tony / Antoine R. Dumont (@ardumont) - gpg fingerprint BF00 203D 741A C9D5 46A8 BE07 52E2 E984 0D10 C3B8 Timothy Sample writes: > Hello, > > This is very exciting work, thanks everyone! > > "Antoine R. Dumont (@ardumont)" writes: > >> FWIW, in the "new" lister [1] implementation, there are a bunch of extra >> computations done [1] to try and resolve those situations. It's trying >> to fetch more information from upstream server (e.g. crates urls which >> ends in /download, ...) now. It's probably not exhaustive though. >> >> [1] >> https://gitlab.softwareheritage.org/swh/devel/swh-lister/-/blob/master/swh/lister/nixguix/lister.py?ref_type=heads > > I was just looking over some of the new results and noticed that crates > are being treated as ‘content’ rather than ‘tarball-directory’. E.g.: > > https://webapp.staging.swh.network/browse/content/sha1_git:e05b33b2d3b40254ceaaa5fe4c501d1b15c75ea6/?origin_url=https://crates.io/api/v1/crates/diff/0.1.12/download > > Is that because the changes you describe were done after the staging > data was loaded or is it a bug? > > > -- Tim signature.asc Description: PGP signature
RE: [swh-devel] Call for public review - SWH Nix/GNU Guix stack
>> My understanding is that so far these URLs were ignored by the >> lister/loader because they didn’t end in *.tar.*.⁰ FWIW, in the "new" lister [1] implementation, there are a bunch of extra computations done [1] to try and resolve those situations. It's trying to fetch more information from upstream server (e.g. crates urls which ends in /download, ...) now. It's probably not exhaustive though. [1] https://gitlab.softwareheritage.org/swh/devel/swh-lister/-/blob/master/swh/lister/nixguix/lister.py?ref_type=heads >> I’m sure Simon Tournier (Cc’d) already discussed with others at SWH >> how crucial it is for us to be able to query content by nar hash. > So yeah, we are looking forward to some ExtID interface. :-) Yes, and there is an ongoing merge request about the new interface [2] [2] https://gitlab.softwareheritage.org/swh/devel/swh-web/-/merge_requests/1220 Cheers, tony / Antoine R. Dumont (@ardumont) - gpg fingerprint BF00 203D 741A C9D5 46A8 BE07 52E2 E984 0D10 C3B8 Simon TOURNIER writes: > Hi, > >> The initial NixGuix loader (currently in production) lists and loads >> origins from a manifest, ignoring the specific origins mentioned above. The >> new stack will be able to ingest those origins. It will also optionally >> associate, if present, a NAR hash (specific intrinsic identifier to Nix and >> Guix) to what’s called an ExtID (SWH side). > > Cool! Thank you. > >> Regarding the SWH API reading side of the ExtID though is a work to be done. > > In short, currently Guix relies on SWH API for resolving from > “something” to SWHID, where “something” can be: > > + Git label tag + url > + Git commit hash > + plain url > > Well, the situation is in good shape IMHO – I do not have recent > numbers, say all is fine for 75% of all Guix packages and for 90% of > Guix packages coming from some Git repositories – but still, we have > examples where “Git label tag + url” fails. For one instance, see [1] > pointed by [2]. > > The information – history of history – is there in SWH but it would > require on Guix side to parse the snapshot information and extract as > best as possible; trying several SWH snapshots until a match. Something > like that. Chance of success until completion? Weak. :-) > > Moreover, what about the missing 25%? They are Guix packages coming > from Mercurial repositories or from Subversion repositories or some > others. > > Back on October 2020, we had discussion [3] for sending a save request > for packages using SVN checkouts but at the time we did not have a clear > path for retrieving. Then on March 2023, maybe an path for retrieving > with this discussion [4]… but still many hacks are required [5]. > > Again, the information is there in SWH but it would require on Guix side > to parse the snapshot information and extract as best as possible; > trying several SWH snapshots until a match. Something like that. > Chance of success until completion? Weak. :-) > > If only one source is missing, all the castle potentially falls down. > Somehow, > a dictionary from ExtID as nar hash to SWHID would help to have the > castle more robust. :-) > > The SWH archive coverage of Guix packages would not be 75% because we, on > Guix side, are not able to know or retrieve these missing 25%. Such > dictionary > could reinforce the bridge between reproducible computational environment > and archiving, IMHO. > > So yeah, we are looking forward to some ExtID interface. :-) > > Cheers, > simon > > > 1: https://issues.guix.gnu.org/66015#0-lineno53 > 2: > https://gitlab.softwareheritage.org/swh/devel/swh-loader-git/-/issues/4751#note_148587 > 3: https://issues.guix.gnu.org/43442#9 > 4: https://sympa.inria.fr/sympa/arc/swh-devel/2023-03/msg9.html > 5: https://issues.guix.gnu.org/43442#13 signature.asc Description: PGP signature
Re: File search
Hello Guix,
Thanks for the feedback!
Note: @civodul, assuming you are subscribed to the ml, I currently kept
you as a `To:` recipient but I can drop you from it, right? I'm "also"
subscribed to the ml so you may drop me from the `To:` too (if i'm not
mistaken).
Ludovic Courtès writes:
> Hi Antoine!
> "Antoine R. Dumont (@ardumont)"
> skribis:
>
>> Here is the rough changelog:
>>
>> - The local db cache is now versioned. Migration will transparently
>> happen for users at each index command calls (if need be).
>
> Perfect!
>
>> - The cli parsing got rewritten to be more flexible (inspired from
>> existing code from guix, notably `guix home`).
>>
>> - We can now choose the indexation method using the
>> `--with-method={store|manifests}` flag. The "manifests" method is the
>> default, seel the help message for more details).
>
> Excellent. (I think we can call it ‘--method’, without “with”.)
sure.
>> - Finally, the indexation methods are displayed using a progress bar.
>
> Yay, I love progress bars. :-)
I have some work to improve the implementation to have more details in
the messages (typically make the "prefix" parameter of
`progress-report/bar` be a callable/function [1]...). If that's of some
interest, i'll push forward (in another patch maybe?). I stopped at the
moment 'cause i had some strange issues with my env (where i could not
make guile see the changes for some reasons...). Anyway, that's of
lesser priority than the rest so...
[1] or whatever the name is in guile context ;)
>> Heads up, I did not yet address the "output" part. Thanks @zimoun for
>> the clarification btw ;)
>
> Future work. ;-)
ok!
If i'm getting out of all the modifications i need to do, and if I have
some energy left, I might attend to it too ;)
>>> In the package case, the number of packages is known ahead.
>>
>> @civodul For the index 'store' implementation, ^ I did not find that
>> information.
>
> (length (all-packages)) gives you the total number of packages you’re
> going to traverse. ‘all-packages’ is not instantaneous, but as a good
> approximation the time spent in ‘all-packages’ can be ignored.
ok. I missed that.
Although, the current call to `fold-packages` does some package
filtering first. So, I guess that's why you call `(length
(all-packages))` an approximation (no filtering on that call), right?
>> So, as a costly implementation detail, I'm folding over all packages
>> first to know the total number of packages (for the progress bar). And
>> then another round trip to actually do the insert.
>
> You could build up the package list just once and call ‘length’ on it.
I explained myself wrongly. That's what it is doing currenly. It does
that ^ folding and keep the packages list, then do a `length` call on it
to have the exact number of entries. And then does the actual loop on
that list to insert them in the db cache.
I naively thought that the `length` call on the list would cost one
round trip O(n), isn't it so? Or is there some memoization somewhere?
>> Hope you'll find it mostly to your taste!
>
> I do!
\o/
>> Note: I gather we'll rework the commits at some point (when it's ready)
>> so I did not bother too much right now.
>
> I think at this point we could consider integration in Guix proper,
> under ‘guix/scripts’. For that we could dismiss commit history.
Fine with me. I'll do the adaptations to make it a script then.
> That’ll entail extra work (d’oh!) such as fine-tuning, writing tests,
> and writing a section for the manual.
Yes, i'm fine with that.
FWIW, I tried to have a look at how current unit tests were written last
week. I did not grok it entirely yet. I saw some script tests generate
some guile and I got lost there ;) I'll have to double check.
I'll probalby need some help for testing and documentation. I guess
asking questions on irc is fine for that part, right?
> The other option, if you prefer, would be to keep it in a separate repo
> as an extension that people can install. To me that would be more of a
> temporary solution because I think it’s a useful feature that ought to
> be provided by Guix proper eventually.
> WDYT? :-)
If it's temporary then i'm fine with trying to do the extra work to
merge the work with proper Guix ;).
Although, zimoun, down thread has some interesting remarks too. I'll
let you discuss those.
I have another extension idea [1] that might help anyway. So we'll have
another opportunity to entertain the guix extensions features (if the
idea is interesting to proper Guix).
[1] `guix bug-report [--with-uname|--with-version|...]`
> Ludo’.
Cheers,
--
tony / Antoine R. Dumont (@ardumont)
-
gpg fingerprint BF00 203D 741A C9D5 46A8 BE07 52E2 E984 0D10 C3B8
signature.asc
Description: PGP signature
Re: File search
Hello,
As mentioned last week (on irc), I've improved a bit the implementation
as per the last discussions in the thread. Please, find enclosed the
patch with those changes (hopefully a tad better attached than last
time...).
Here is the rough changelog:
- The local db cache is now versioned. Migration will transparently
happen for users at each index command calls (if need be).
Note: Care should be taken by devs to provide the migration script
step for each db schema bump (examples inside). The rest will happen
on its own.
- The cli parsing got rewritten to be more flexible (inspired from
existing code from guix, notably `guix home`).
- We can now choose the indexation method using the
`--with-method={store|manifests}` flag. The "manifests" method is the
default, seel the help message for more details).
- Finally, the indexation methods are displayed using a progress bar.
Heads up, I did not yet address the "output" part. Thanks @zimoun for
the clarification btw ;)
> In the package case, the number of packages is known ahead.
@civodul For the index 'store' implementation, ^ I did not find that
information.
So, as a costly implementation detail, I'm folding over all packages
first to know the total number of packages (for the progress bar). And
then another round trip to actually do the insert.
I don't like it at all. Plus, that number seems off to me (21696)
packages in regards to the number of packages indexed (522). So, if you
could have a rapid look to fix or tell me what's wrong, that'd be great.
I'm pretty sure it will hit you immediately (while i still do not find
it ¯\_(ツ)_/¯ ;).
Here is a rapid sample of the current command usage:
--8<---cut here---end--->8---
$ guix index --version
Extension local cache database:
- path: /home/tony/.cache/guix/index/db.sqlite
- version: 2
guix index (GNU Guix) 5ccb5837ccfb39af4e3e6399a0124997a187beb1
Copyright (C) 2022 the Guix authors
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ guix index --with-method=store --db-path=/tmp/db/db.sqlite
Registering 21696 packages [ ]
$ guix index search git
...
git-minimal@2.38.1
/gnu/store/xf734fz3jihgc5x4979ypyaxn8aday1k-git-minimal-2.38.1/bin/git
git@2.38.1
/gnu/store/wx965ym3c5fwbcdp7i9lvzad3479vv7m-git-2.38.1/libexec/git-core/git
git@2.38.1
/gnu/store/wx965ym3c5fwbcdp7i9lvzad3479vv7m-git-2.38.1/etc/bash_completion.d/git
git@2.38.1
/gnu/store/wx965ym3c5fwbcdp7i9lvzad3479vv7m-git-2.38.1/bin/git
$ guix index --help
Usage: guix index [OPTIONS...] [search FILE...]
Without argument, indexes (package, file) relationships from the machine.
This allows indexation with 2 methods:
- out of the local manifests. This is the fastest implementation but this
indexes less packages. That'd be typically the use case for user local
indexation.
- out of the local store. This is slower due to implementation details (it
discusses with the store daemon for one). That'd be typically the use case for
building the largest db in one of the build farm node.
With 'search FILE', search for packages installing FILE.
Note: Internal cache is located at ~/.cache/guix/index/db.sqlite by default.
See --db-path for customization.
The valid values for OPTIONS are:
-h, --help Display this help and exit
-V, --version Display version information and exit
--db-path=DIR Change default location of the cache db
--with-method=METH Change default indexation method. By default it uses the
local "manifests" (faster). It can also uses the local
"store" (slower, typically on the farm build ci).
The valid values for ARGS are:
search FILE Search for packages installing the FILE (from cache db)
Without any argument, it index packages. This fills in the
db cache using whatever indexation method is defined.
Report bugs to: bug-g...@gnu.org.
GNU Guix home page: <https://guix.gnu.org>
General help using Guix and GNU software: <https://guix.gnu.org/en/help/>
--8<---cut here---end--->8---
Hope you'll find it mostly to your taste!
Note: I gather we'll rework the commits at some point (when it's ready)
so I did not bother too much right now.
Cheers,
--
tony / Antoine R. Dumont (@ardumont)
-
gpg fingerprint BF00 203D 741A C9D5 46A8 BE07 52E2 E984 0D10 C3B8
From d3e658ca1e3ce2715e25450b794d139d3417c74c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?=
Date: Wed, 30 Nov 2022 15:25:21 +0100
Subject: [PATCH 01/25] extensions-index: Add initial implementation from
civodul
Related to http
Re: File search
Hello, > So we went from 413s to 11s (on the Guix System node) for only 6% fewer > files in the latter case? Do I get that right? That’s pretty cool. Not 6% of loss, a bit more, around half is only detected between the first and second round. Here is the summary [1] (org-mode) table I should have sent to ease reading. I don't have a better dataset to test against so you tell me if it is still worth pushing in that direction ;) [1] |---+-+--+--| | Iteration | Host System | Time (s) | Packages | |---+-+--+--| | 1st | Debian | 121.88 | 284 | | | Guix System | 413.55 | 749 | |---+-+--+--| | 2nd | Debian | 1.3 | 101 | | | Guix System |11.54 | 354 | |---+-+--+--| > It should instead show “git@2.38.1:send-email”. We probably need an > ‘output’ field in the ‘Packages’ table. Why must that be "git@2.38.1:send-email", what does it mean? Providing we continue on that direction (see first question above), I'll check what i can do (I'm not sure how to properly do that just yet). > Also going forward we’ll need a schema version, as in: yes, that I see how to do. > Oh, and progress bars too. I'm a bit unsettled on this. Hopefully it was mostly a joke ;) If it's serious, how can we implement this as we don't know in advance how many packages we'll discover locally (if we don't change the current approach, that is, to avoid incurring too much time penalty). And also, what implem should be used, I know the "pv" package provide some pipe utility for that but that's about it. Do you have some example in the guix codebase that does some progress bar already? > And a pony. :-) ;p Cheers, -- tony / Antoine R. Dumont (@ardumont) - gpg fingerprint BF00 203D 741A C9D5 46A8 BE07 52E2 E984 0D10 C3B8 Ludovic Courtès writes: > Howdy! > > "Antoine R. Dumont (@ardumont)" > skribis: > >> Please, find enclosed the latest implementation as a patch (somewhat vcs >> code ;). I've edited commits to mark Ludo as author with his >> started/amended implementations first [0] (that should be in the patch). > > Nice! > >> For information, I extracted some number from runs to compare our >> iterations (see the org-file attachment). The first iteration being >> "extracts packages from the store" and the second one "extracts packages >> from the system manifest". Those runs happened both on a guixified >> debian host and a raw guix host (more packages). > > So we went from 413s to 11s (on the Guix System node) for only 6% fewer > files in the latter case? Do I get that right? That’s pretty cool. > > The implementation based on manifests can of course miss packages, so > it’s a tradeoff. Purely local indexing will only find packages you > already have anyway, so eventually we’ll need a second mode that would > download a database. > > BTW, I noticed outputs are not properly handled so far, as in this > example: > > --8<---cut here---start->8--- > $ GUIX_EXTENSIONS_PATH=$HOME/tmp/guix-index guix index search git-send-email > git@2.38.1 > /gnu/store/g3lgyzr749l76qma7srycclgsm0f78iq-git-2.38.1-send-email/libexec/git-core/git-send-email > git@2.37.1 > /gnu/store/n3hkzz5ydm0qm1c2jja2pwy2v19mq1k0-git-2.37.1-send-email/libexec/git-core/git-send-email > --8<---cut here---end--->8--- > > It should instead show “git@2.38.1:send-email”. We probably need an > ‘output’ field in the ‘Packages’ table. > > Also going forward we’ll need a schema version, as in: > > --8<---cut here---start->8--- > create table SchemaVersion ( > version integer not null; > ); > --8<---cut here---end--->8--- > > so that the tool can upgrade or discard databases that have the wrong > version. > > Oh, and progress bars too. And a pony. :-) > > Thanks for your work! > > Ludo’. signature.asc Description: PGP signature
Re: File search
Hello Guix, Ludo, \o/, thanks for the iteration ;) Not that I understood everything yet but indeed, it's faster. I've iterated over your work to: - align calls to that new function - improve some docstrings, and imports, and the help message - drop dead (or redundant) code - make sure the (xdg) folder holding the db is created if needed Please, find enclosed the latest implementation as a patch (somewhat vcs code ;). I've edited commits to mark Ludo as author with his started/amended implementations first [0] (that should be in the patch). For information, I extracted some number from runs to compare our iterations (see the org-file attachment). The first iteration being "extracts packages from the store" and the second one "extracts packages from the system manifest". Those runs happened both on a guixified debian host and a raw guix host (more packages). It seems with the new implementation, we find less a bit less packages but it's faster so i guess it's a tradeoff. It'd be nice to know how it runs on your build farm machine (if you got the time at some point [1]). [0] fwiw, yeah git and magit! :D [1] I noticed (through ml discussions) you all are quite busy at the moment ;) Cheers, -- tony / Antoine R. Dumont (@ardumont) - gpg fingerprint BF00 203D 741A C9D5 46A8 BE07 52E2 E984 0D10 C3B8 Ludovic Courtès writes: > Yay, nice work! > > I toyed a bit with your code and that gave me an idea: instead of the > costly ‘fold-packages’ + ‘package-derivation’, we can iterate over all > the manifests on the system and index packages they refer to. That way, > no need to talk to the daemon, computer derivations, etc. Should be > faster, though of course it still needs to traverse those directories. > > Please find attached a modified version that illustrates that. (We’ll > need version control at some point. :-)) > > Thanks, > Ludo’. > > ;;; GNU Guix --- Functional package management for GNU > ;;; Copyright © 2022 Ludovic Courtès > ;;; > ;;; This file is part of GNU Guix. > ;;; > ;;; GNU Guix is free software; you can redistribute it and/or modify it > ;;; under the terms of the GNU General Public License as published by > ;;; the Free Software Foundation; either version 3 of the License, or (at > ;;; your option) any later version. > ;;; > ;;; GNU Guix is distributed in the hope that it will be useful, but > ;;; WITHOUT ANY WARRANTY; without even the implied warranty of > ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > ;;; GNU General Public License for more details. > ;;; > ;;; You should have received a copy of the GNU General Public License > ;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>. > > (define-module (guix extensions index) > #:use-module (guix config) ;; %guix-package-name, ... > #:use-module (guix ui) ;; display G_ > #:use-module (guix scripts) > #:use-module (sqlite3) > #:use-module (ice-9 match) > #:use-module (guix describe) > #:use-module (guix store) > #:use-module (guix monads) > #:autoload (guix combinators) (fold2) > #:autoload (guix grafts) (%graft?) > #:autoload (guix store roots) (gc-roots) > #:use-module (guix derivations) > #:use-module (guix packages) > #:use-module (guix profiles) > #:use-module (guix sets) > #:use-module ((guix utils) #:select (cache-directory)) > #:autoload (guix build utils) (find-files) > #:autoload (gnu packages) (fold-packages) > #:use-module (srfi srfi-1) > #:use-module (srfi srfi-9) > #:use-module (srfi srfi-71) > #:export (guix-index)) > > (define debug #f) > > (define schema > " > create table if not exists Packages ( > idinteger primary key autoincrement not null, > name text not null, > version text not null, > unique(name, version) -- add uniqueness constraint > ); > > create table if not exists Directories ( > idinteger primary key autoincrement not null, > name text not null, > package integer not null, > foreign key (package) references Packages(id) on delete cascade, > unique (name, package) -- add uniqueness constraint > ); > > create table if not exists Files ( > name text not null, > basename text not null, > directory integer not null, > foreign key (directory) references Directories(id) on delete cascade > unique (name, basename, directory) -- add uniqueness constraint > ); > > create index if not exists IndexFiles on Files(basename);") > > (define (call-with-database file proc) > (let ((db (sqlite-open file))) > (dynamic-wind > (lambda () #t) > (lambda () > (s
Re: File search
Hello again, As mentioned previously, I have iterated on the work @civodul started. After discussing it a bit over irc, I proposed to try and push a bit forward the discussion and the implementation [2] to see where this goes. After toying a bit with the initial code, I took the liberty to make it a guix extension (we discussed it a bit with @zimoun). It was mostly to get started with Guile (I know some lisp implems but not this one so i had to familiarize myself with tools and whatnot ;). Anyway, that can be reverted if you feel like it can be integrated as a Guix cli directly. Currently, the implementation scans and indexes whatever package is present in the local store of the machine's user. From nix/guix's design, it makes sense to do it that way as it's likely that even though you don't have all the tools locally, it may be already present as a dependency of some high level tools you already use (it's just not exposed because not declared in config.scm or home-configuration.scm). You will find inlines (at the bottom) some cli usage calls [1] and the current implementation [2]. Thanks in advance for any feedback ;) Cheers, -- tony / Antoine R. Dumont (@ardumont) - gpg fingerprint BF00 203D 741A C9D5 46A8 BE07 52E2 E984 0D10 C3B8 [1] Usage sample: --8<---cut here---start->8--- $ env | grep GUIX_EXTENSION GUIX_EXTENSIONS_PATH=$HOME/repo/public/guix/guix/guix/extensions $ guix index ;;; (package 1 "acl") ;;; (package 595 "shepherd") ;;; (package 596 "guile2.2-shepherd") ;;; (package 2 "htop") ;;; (package 7 "shadow") ;;; (package 6 "shepherd") ;;; (package 5 "autojump") ... ^C $ guix index search shepherd guile2.2-shepherd@0.9.3 /gnu/store/cq8r2vzg56ax0iidgs4biz3sv0b9jxp3-guile2.2-shepherd-0.9.3/bin/shepherd shepherd@0.9.3 /gnu/store/a9jdd8kgckwlq97yw3pjqs6sy4lqgrfq-shepherd-0.9.3/bin/shepherd shepherd@0.8.1 /gnu/store/vza48khbaq0fdmcsrn27xj5y5yy76z6l-shepherd-0.8.1/bin/shepherd shepherd@0.9.1 /gnu/store/gxz67p4gx9g6rpxxpsgmhsybczimdlx5-shepherd-0.9.1/bin/shepherd guix help | grep -C3 extension repl read-eval-print loop (REPL) for interactive programming extension commands index Index packages to allow searching package for a given filename Report bugs to: bug-g...@gnu.org. $ guix help index # or: guix index [--help|-h] Usage: guix index [OPTIONS...] [search FILE...] Without FILE, index (package, file) relationships in the local store. With 'search FILE', search for packages installing FILE. Note: The internal cache is located at ~/.config/guix/locate-db.sqlite. See --db-path for customization. The valid values for OPTIONS are: -h, --help Display this help and exit -V, --version Display version information and exit --db-path=DIR Change default location of the cache db The valid values for ARGS are: search FILE Search for packages installing the FILE (from cache db) Report bugs to: bug-g...@gnu.org. GNU Guix home page: <https://guix.gnu.org> General help using Guix and GNU software: <https://guix.gnu.org/en/help/> $ guix index --version # or guix index -V guix locate (GNU Guix) 5ccb5837ccfb39af4e3e6399a0124997a187beb1 Copyright (C) 2022 the Guix authors License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. --8<---cut here---start->8--- [2] The code: --8<---cut here---start->8--- ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2022 Ludovic Courtès ;;; ;;; This file is part of GNU Guix. ;;; ;;; GNU Guix is free software; you can redistribute it and/or modify it ;;; under the terms of the GNU General Public License as published by ;;; the Free Software Foundation; either version 3 of the License, or (at ;;; your option) any later version. ;;; ;;; GNU Guix is distributed in the hope that it will be useful, but ;;; WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;; GNU General Public License for more details. ;;; ;;; You should have received a copy of the GNU General Public License ;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>. (define-module (guix extensions index) #:use-module (guix config) ;; %guix-package-name, ... #:use-module (guix ui) ;; display G_ #:use-module (guix scripts) #:use-module (sqlite3) #:use-module (ice-9 match) #:use-module (guix describe) #:use-module (guix store) #:use-module (guix monads) #:autoload (guix grafts) (%graft?) #:use-module (guix derivations) #:use-module (guix packages) #:autoload (guix build utils) (find-files)
