NLNet grant "Next Generation Internet -- Search & discovery": I'm in!

NLNet grant "Next Generation Internet -- Search & discovery": I'm in!

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 6507 bytes --]

Dear Guix community!

I'm happy to let your know that my application to the NLNet "Next
Generation Internet -- Search & Discovery" grant for Guix has been
accepted!

See https://nlnet.nl/project/GUIX/ (the description is misleading, see below).
See also the European Union initiative website: https://www.ngi.eu/.

This will allow me to work on Guix for a flexible period, probably between 6
months and 1 year.

The bad news: Nope, IPFS is not part of the grant! :p  So I won't be working on
it myself in the context of NGI.  But who knows, if I get extra time... (Or
anyone else ;p).

Here follows the current plan (subject to change).  Ideas are welcome!



/The main goal is to enhance search and discovery of Guix packages and services
via a catalogue. The subgoal is to complete what “packages” and “services” are in
Guix by completing them and broadening their domain./

1. Parameterized packages
   (Previous discussion: https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html)

   Gentoo’s package manager, Portage, exposes a “USE flags” feature which allows
   users to customize packages in a way that composes (e.g. “disable the GUI
   elements of all packages” for a headless server).  This essentially subdivides
   packages into smaller “components.”  Since those components form the smallest
   atoms a user could search for, this is a prerequisite for the rest of the
   searchability improvements.

   Milestone(s)
   * Implement parameterized package support (mostly Guile code).
   * Write tests.
   * Document.
   * Community review.

2. File search
   (Previous discussion: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00236.html)

   Many package managers support looking up packages by the file paths they
   include.  This feature is missing in Guix while being crucial for search,
   e.g. when the user knows the executable name which happens to be different
   from the package name.

   Milestone(s)
   * Implement file paths caching in the daemon (mostly C++).
   * Implement high-level command line interface for file search (mostly Guile).
   * Write tests.
   * Document.
   * Community review.
   * Deploy on the build farms.

3. User services

   Previous discussions:
   - Guix shepherd user services: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00128.html
   - Julien's home manager: https://lists.gnu.org/archive/html/guix-devel/2019-09/msg00185.html
   - Nix Home Manager: https://nixos.wiki/wiki/Home_Manager
   I believe there were many more discussion on user services on the
   mailing list, feel free to share them!

   Guix provides excellent integration with GNU Shepherd for system services (all
   configurations are programmable and composable using Guile).  But it lacks
   integration for user services.  User services can be used to replace much of the
   traditional “dotfiles” which are often ad-hoc hacks (e.g. environment variables,
   scripts, various program configurations such as GnuPG).  The benefit is as for
   packages: the work of one can be redistributed to many.  Finally, services are
   not searchable with Guix.  We could fix this issue.

   Milestone(s)
   * Integrate Guix with GNU Shepherd to support user services.  A user service
     should then automatically require the necessary packages, just like a
     system service does.  For instance if the user sets up a GnuPG service,
     they don’t have to install GnuPG explicitly, Guix+Shepherd will take care
     of that.
   * Implement service search.
   * Write tests.
   * Document.
   * Community review.

4. Graphical user interface (GUI)

   *Question*: I recently read an email about someone (an intern?) working on a
   graphical installer.  Can't find the email back though.  Is someone still
   working on it?  There could be a lot of work to factor here.

   Guix comes with a command line interface and some Emacs interfaces.  None of
   them are particularly newcomer-friendly.  Besides, much of the configuration is
   done by editing Guile files.  The goal of this task is to make Guix more
   accessible to non-tech users by providing an intuitive user interface to most of
   Guix actions.

   Milestone(s)
   * Discuss with the Accessibility Group for the requirements.
   * Implement the GUI using Gobject-Introspection (Guile).
     1. Live fuzzy-search.
     2. Search packages.
     3. Search file paths.
     4. Search system/user services.
     5. Configuration editor (generates a Guile configuration).
   * Write tests.
   * Document.
   * Community review.

5. Social integration with the Guix catalogue

   Previous discussions:
   - Adding wikidata, wikipedia & screenshot-url fields to	package-recipes: https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00007.html
   - Re-approaching package tagging: https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00385.html
   - New library: guile-wikidata: https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00107.html
   - Guix <-> Wikidata: https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00017.html
   - Guix Wikidata module - next steps: https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00089.html

   There were also a few discussions regarding package search improvements, in
   which has Zimoun participated quite a bit if I recall correctly.  Feel free
   to share all your precious links! :)

   Guix packages can be search from the package name, the synopsis (a one-liner)
   and the description (a paragraph).  The goal here is to extend the
   discoverability of both packages and services thanks to a catalogue.  If
   possible, we would like to make it possible to a wide audience to contribute to
   such a catalogue.

   Milestone(s)
   * Discuss with Guix, Nix, Debian and other distributions about the
     possibility to centralize the catalogue.  What about using Wikidata?
   * Implement the catalogue.
     1. Add package recommendation suggestions.
     2. Add (optionally anonymous) statistics (e.g. number of downloads).
     3. Add (optionally anonymous) ratings.
     4. Add tag lookup for packages/services.
   * Integrate the catalogue with Guix command line (mostly Guile).
   * Integrate the catalogue with the Guix GUI (mostly Guile).
   * Write tests.
   * Document.
   * Community review.

--
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!

[Pjotr Prins]

That is great news Pierre :)

On Fri, Dec 13, 2019 at 03:48:37PM +0100, Pierre Neidhardt wrote:
> Dear Guix community!
> 
> I'm happy to let your know that my application to the NLNet "Next
> Generation Internet -- Search & Discovery" grant for Guix has been
> accepted!
> 
> See https://nlnet.nl/project/GUIX/ (the description is misleading, see below).
> See also the European Union initiative website: https://www.ngi.eu/.
> 
> This will allow me to work on Guix for a flexible period, probably between 6
> months and 1 year.
> 
> The bad news: Nope, IPFS is not part of the grant! :p  So I won't be working on
> it myself in the context of NGI.  But who knows, if I get extra time... (Or
> anyone else ;p).
> 
> Here follows the current plan (subject to change).  Ideas are welcome!
> 
> 
> 
> /The main goal is to enhance search and discovery of Guix packages and services
> via a catalogue. The subgoal is to complete what “packages” and “services” are in
> Guix by completing them and broadening their domain./
> 
> 1. Parameterized packages
>    (Previous discussion: https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html)
> 
>    Gentoo’s package manager, Portage, exposes a “USE flags” feature which allows
>    users to customize packages in a way that composes (e.g. “disable the GUI
>    elements of all packages” for a headless server).  This essentially subdivides
>    packages into smaller “components.”  Since those components form the smallest
>    atoms a user could search for, this is a prerequisite for the rest of the
>    searchability improvements.
> 
>    Milestone(s)
>    * Implement parameterized package support (mostly Guile code).
>    * Write tests.
>    * Document.
>    * Community review.
> 
> 2. File search
>    (Previous discussion: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00236.html)
> 
>    Many package managers support looking up packages by the file paths they
>    include.  This feature is missing in Guix while being crucial for search,
>    e.g. when the user knows the executable name which happens to be different
>    from the package name.
> 
>    Milestone(s)
>    * Implement file paths caching in the daemon (mostly C++).
>    * Implement high-level command line interface for file search (mostly Guile).
>    * Write tests.
>    * Document.
>    * Community review.
>    * Deploy on the build farms.
> 
> 3. User services
> 
>    Previous discussions:
>    - Guix shepherd user services: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00128.html
>    - Julien's home manager: https://lists.gnu.org/archive/html/guix-devel/2019-09/msg00185.html
>    - Nix Home Manager: https://nixos.wiki/wiki/Home_Manager
>    I believe there were many more discussion on user services on the
>    mailing list, feel free to share them!
> 
>    Guix provides excellent integration with GNU Shepherd for system services (all
>    configurations are programmable and composable using Guile).  But it lacks
>    integration for user services.  User services can be used to replace much of the
>    traditional “dotfiles” which are often ad-hoc hacks (e.g. environment variables,
>    scripts, various program configurations such as GnuPG).  The benefit is as for
>    packages: the work of one can be redistributed to many.  Finally, services are
>    not searchable with Guix.  We could fix this issue.
> 
>    Milestone(s)
>    * Integrate Guix with GNU Shepherd to support user services.  A user service
>      should then automatically require the necessary packages, just like a
>      system service does.  For instance if the user sets up a GnuPG service,
>      they don’t have to install GnuPG explicitly, Guix+Shepherd will take care
>      of that.
>    * Implement service search.
>    * Write tests.
>    * Document.
>    * Community review.
> 
> 4. Graphical user interface (GUI)
> 
>    *Question*: I recently read an email about someone (an intern?) working on a
>    graphical installer.  Can't find the email back though.  Is someone still
>    working on it?  There could be a lot of work to factor here.
> 
>    Guix comes with a command line interface and some Emacs interfaces.  None of
>    them are particularly newcomer-friendly.  Besides, much of the configuration is
>    done by editing Guile files.  The goal of this task is to make Guix more
>    accessible to non-tech users by providing an intuitive user interface to most of
>    Guix actions.
> 
>    Milestone(s)
>    * Discuss with the Accessibility Group for the requirements.
>    * Implement the GUI using Gobject-Introspection (Guile).
>      1. Live fuzzy-search.
>      2. Search packages.
>      3. Search file paths.
>      4. Search system/user services.
>      5. Configuration editor (generates a Guile configuration).
>    * Write tests.
>    * Document.
>    * Community review.
> 
> 5. Social integration with the Guix catalogue
> 
>    Previous discussions:
>    - Adding wikidata, wikipedia & screenshot-url fields to	package-recipes: https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00007.html
>    - Re-approaching package tagging: https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00385.html
>    - New library: guile-wikidata: https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00107.html
>    - Guix <-> Wikidata: https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00017.html
>    - Guix Wikidata module - next steps: https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00089.html
> 
>    There were also a few discussions regarding package search improvements, in
>    which has Zimoun participated quite a bit if I recall correctly.  Feel free
>    to share all your precious links! :)
> 
>    Guix packages can be search from the package name, the synopsis (a one-liner)
>    and the description (a paragraph).  The goal here is to extend the
>    discoverability of both packages and services thanks to a catalogue.  If
>    possible, we would like to make it possible to a wide audience to contribute to
>    such a catalogue.
> 
>    Milestone(s)
>    * Discuss with Guix, Nix, Debian and other distributions about the
>      possibility to centralize the catalogue.  What about using Wikidata?
>    * Implement the catalogue.
>      1. Add package recommendation suggestions.
>      2. Add (optionally anonymous) statistics (e.g. number of downloads).
>      3. Add (optionally anonymous) ratings.
>      4. Add tag lookup for packages/services.
>    * Integrate the catalogue with Guix command line (mostly Guile).
>    * Integrate the catalogue with the Guix GUI (mostly Guile).
>    * Write tests.
>    * Document.
>    * Community review.
> 
> --
> Pierre Neidhardt
> https://ambrevar.xyz/

Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

Pierre,

Pierre Neidhardt 写道：
> I'm happy to let your know that my application to the NLNet 
> "Next
> Generation Internet -- Search & Discovery" grant for Guix has 
> been
> accepted!

Yay!  The second joyful announcement on guix-devel this week.

> 1. Parameterized packages
>    (Previous discussion: 
>    https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html)
>
>    Gentoo’s package manager, Portage, exposes a “USE flags” 
>    feature which allows
>    users to customize packages in a way that composes 
>    (e.g. “disable the GUI
>    elements of all packages” for a headless server).  This 
>    essentially subdivides
>    packages into smaller “components.”  Since those components 
>    form the smallest
>    atoms a user could search for, this is a prerequisite for the 
>    rest of the
>    searchability improvements.

Very curious to see where this goes.  Do you have any other 
examples of distributions that attack this problem in (more) 
interesting ways than Gentoo?

The inevitable “oooh, you mean like USE flags” mental 
shortc(irc)ut that this subject inevitably triggers seems stifling 
to me… but it affects me as well and I don't have any better 
ideas.

Thank you, and good luck!

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 159 bytes --]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> That is great news Pierre :)

Indeed!  Happy times! :D

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

Hi Tobias!

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Yay!  The second joyful announcement on guix-devel this week.

I see many joyful announcements! :p  So which was the first one?

>> 1. Parameterized packages
>>    (Previous discussion: 
>>    https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html)
>>
>>    Gentoo’s package manager, Portage, exposes a “USE flags” 
>>    feature which allows
>>    users to customize packages in a way that composes 
>>    (e.g. “disable the GUI
>>    elements of all packages” for a headless server).  This 
>>    essentially subdivides
>>    packages into smaller “components.”  Since those components 
>>    form the smallest
>>    atoms a user could search for, this is a prerequisite for the 
>>    rest of the
>>    searchability improvements.
>
> Very curious to see where this goes.  Do you have any other 
> examples of distributions that attack this problem in (more) 
> interesting ways than Gentoo?

I'm not aware of any other USE-flag-like system beside Gentoo
derivatives like Funtoo.

> The inevitable “oooh, you mean like USE flags” mental 
> shortc(irc)ut that this subject inevitably triggers seems stifling 
> to me… but it affects me as well and I don't have any better 
> ideas.

Oh, it's no mental shortcut, I wrote "USE flags" explicitly! ;)

I've used Gentoo myself for a while and I have experience the USE-flags
nightmare first hand...  I'd hate to inflict this scourge onto Guix!
That said, I believe that the functional aspect of Guix + the
programming language can help us tremendously here.  We will see when
time comes to discuss this more in depth.

> Thank you, and good luck!

Thanks!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!

[zimoun]

Hi Pierre,

Congrats!


On Fri, 13 Dec 2019 at 15:49, Pierre Neidhardt <mail@ambrevar.xyz> wrote:

> 2. File search
>    (Previous discussion: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00236.html)

Yes, it is really lacking. For example, if one wants to use the 'hg'
control version system, then one will naively search "guix search hg"
and this will return "Human Genome" packages (useful in bioinformatics
stuff). Worse, because the description/synopsis of the package which
provides the command 'hg' do not mention the term 'hg', it is
impossible to reach it if one does not know that it is provided by the
very package mercurial. So, what I am personally doing is: DuckDuckGo,
look at some Debian packages and hope it is the same name in Guix.
Ouch!

And it is super useful to find headers. You have a code with "#include
<name-it.h>" and it is hard to know which Guix package provides this
very header 'name-it.h'.


However, IMHO, the "filesearch" should be included in the "search"
command and not another command. I mean:

  guix package --file-search=hg
or
 guix search hg --file-search

It appears to me a better UI than adding again another subcommand. :-)


> 5. Social integration with the Guix catalogue
>
>    Previous discussions:
>    - Adding wikidata, wikipedia & screenshot-url fields to      package-recipes: https://lists.gnu.org/archive/html/guix-devel/2018-11/msg00007.html
>    - Re-approaching package tagging: https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00385.html
>    - New library: guile-wikidata: https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00107.html
>    - Guix <-> Wikidata: https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00017.html
>    - Guix Wikidata module - next steps: https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00089.html
>
>    There were also a few discussions regarding package search improvements, in
>    which has Zimoun participated quite a bit if I recall correctly.  Feel free
>    to share all your precious links! :)

Firstly, IMHO tagging, i.e., assign a specific word belonging to a set
of words, is not a good approach. My main argument is: the set of
words is arbitrary, and at the end, it is bikeshedding and/or it is
not really useful because it is not self-organised by the data
themselves. As a Debian user, I do not use their tag system; and I am
almost sure they have documented the "usefulness" of their tagging
system and the feedback (I have in mind talks in DebConf but I am not
able to find it now).

However, grouping packages by similar topic is important for
discoverybility. The question is: how is the grouping done? Instead of
a manual tagging, I propose to first compare clustering methods based
on synopsis+description and Natural Language Processing (NLP).

It is what I had in mind when I answered to the thread "Re-approaching
package tagging" but life intervened and I did nothing on this front.
Well, the Python ecosystem provides nice packages (most not yet in
Guix last time I checked) to ease the first exploratory and see if it
will pay off or not.

Not about tagging but close enough to be maybe relevant:
https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00133.html
https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00252.html


Secondly, instead of manual tagging, I propose to work on the
relevance scoring. Basically, "guix search" should act as a
recommendation system IMHO. Then the questions are: where is done the
indexing computations? locally? by the Guix Data Service and "guix
pull" will fetch this index? Can be merge with other distro or
upstream (CRAN, github) via wikidata or API? etc.


Well, thirdly I also think that Guix lacks tools to navigate in its
Git history. Now we have "guix time-machine", it appears to me that
finding specific package back in the history is complicated (basically
git checkout+git log+grepouch! not user-friendly). I have tried to
describe use cases in this message.

https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00513.html

IMO, something similar to "git tag" should be added (in "guix pull"?).
But one can also think to integrate such historical information in
Wikidata and for example "guix search emacs --all" will return all the
versions and commits present in Guix, then it is easy to run "guix
time-machine --commit=1234 -- install emacs".
Kind of such ideas... and not fully clear in my mind. ;-)


Last about UI:
https://lists.gnu.org/archive/html/guix-devel/2019-07/msg00289.html

Currently "guix search" supports regexp but part of the filtering is
done by recsel. And I do not find that handy.


Hope that these words make sense.

Cheers,
simon

Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]


> I'm happy to let your know that my application to the NLNet "Next
> Generation Internet -- Search & Discovery" grant for Guix has been
> accepted!

Great, congratulations! :-)

> 1. Parameterized packages
>    (Previous discussion: https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html)

I've been looking for something like this. I want to run a more minimal
system like I used to with Parabola GNU/Linux. I often find Guix's
packages to be too heavy and hard to modify without a lot of
effort. Package inheritance is itself easy to accomplish with Guile code
but getting the modified package to build successfully is sometimes
difficult. It would certainly help if Guix had pre-parameterized
packages that one could modify easily. However, this can enormously
increase the burden on Guix packagers. However, we can discuss that
later when we have more specific proposals.

> 2. File search
>    (Previous discussion: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00236.html)

This feature would be very nice too. Currently, I fall back to one of my
Parabola GNU/Linux installations, and run pkgfile there to get an
approximate idea of what Guix package a certain file might be in.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

Arun Isaac <arunisaac@systemreboot.net> writes:

> Great, congratulations! :-)

Thanks! :)

>> 1. Parameterized packages
>>    (Previous discussion: https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html)
>
> I've been looking for something like this. I want to run a more minimal
> system like I used to with Parabola GNU/Linux. I often find Guix's
> packages to be too heavy and hard to modify without a lot of
> effort. Package inheritance is itself easy to accomplish with Guile code
> but getting the modified package to build successfully is sometimes
> difficult. It would certainly help if Guix had pre-parameterized
> packages that one could modify easily. However, this can enormously
> increase the burden on Guix packagers. However, we can discuss that
> later when we have more specific proposals.

The first thing that comes to my mind is to proceed incrementally
(i.e. add parameters one by one, package by package).  We might be able
to partially automate this by leveraging the build systems (e.g. some
build systems might automatically support building static libraries for
a well known flag).

Well, there is a lot to talk about!

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!

[Ricardo Wurmus]

zimoun <zimon.toutoune@gmail.com> writes:

> Well, thirdly I also think that Guix lacks tools to navigate in its
> Git history. Now we have "guix time-machine", it appears to me that
> finding specific package back in the history is complicated (basically
> git checkout+git log+grepouch! not user-friendly).

I think that the Guix Data Service could be used to answer questions
like that, so it would make sense to implement a way to talk to it from
the Guix command line.

--
Ricardo

Re: NLNet grant "Next Generation Internet -- Search & discovery": I'm in!

[Ludovic Courtès]

Hello!

Congrats, Pierre!  That’s really great news!

Arun Isaac <arunisaac@systemreboot.net> skribis:

>> 1. Parameterized packages
>>    (Previous discussion: https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00285.html)
>
> I've been looking for something like this. I want to run a more minimal
> system like I used to with Parabola GNU/Linux. I often find Guix's
> packages to be too heavy and hard to modify without a lot of
> effort. Package inheritance is itself easy to accomplish with Guile code
> but getting the modified package to build successfully is sometimes
> difficult. It would certainly help if Guix had pre-parameterized
> packages that one could modify easily. However, this can enormously
> increase the burden on Guix packagers. However, we can discuss that
> later when we have more specific proposals.

Yes, I’m very much on the same line of thought: it sounds both exciting
from a user viewpoint (colleagues of mine in HPC would love it) and
scary from a maintainer viewpoint (the configuration space could
explode, how do we ensure we ship packages that actually work?).

Let’s see!

>> 2. File search
>>    (Previous discussion: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00236.html)
>
> This feature would be very nice too. Currently, I fall back to one of my
> Parabola GNU/Linux installations, and run pkgfile there to get an
> approximate idea of what Guix package a certain file might be in.

That’d be great to have.

Thanks,
Ludo’.