Re: Package file indexing

[zimoun]

Hi,

On Thu, 2 Jan 2020 at 18:12, Pierre Neidhardt <address@hidden> wrote:

> Last but not least: previously we suggested adding a subcommand like
> "guix which" or "guix filesearch".  In another thread, Simon suggested
> that this would be a bad idea and factoring the file search into "guix
> search" is probably better.

It appears to me better for 2 reasons:
 1. because obviously "filesearch" is a kind of "search" ;-) so it
adds consistency.
 2. because it allows (in the near future) mixed research: "guix
search bin/hg python" applying the "python" filter only to the
packages returned by "bin/hg". And "guix search python bin/hg" search
the binary file "hg" only to the packages matching "python.


> For instance, we could do
>
>   guix search bin/foo
>
> and it would report the packages containing the "bin/foo" path.  This
> could mean that we need to adapt the output to display the file listing
> as well.  If listing all files would be too verbose, we can list only
> the matching files:
>
> --8<---------------cut here---------------start------------->8---
> name: jami

[...]

> filepaths:
> + bin/foo
> + share/bar/bin/foo-blah
> relevance: 24
> --8<---------------cut here---------------end--------------->8---

How do you compute the relevance/score?

Currently, when searching with regexp, the relevance is computed by
counting the number of matches applying different weights depending on
if the match is about name, synopsis, description, etc. It is not
perfect and there is room of improvements as discussed elsewhere, but
it works (nicely when you know what you are searching ;-).

For example, let consider 2 packages:

 a- 'bin/foo'
 b- 'share/baz/bin/foo'

How to do you order/score the result? What do you expect first? The
package a- I guess.
Therefore, weight should be applied, isn't it?



> That said, some terms may match too frequently.  For instance, "guix
> search lib" would match almost all packages that have libraries and
> result in a huge, useless output.
>
> I suggest the following:
>
> - Add a "--search-file-paths=[auto|on|off]" option.

I do not find this option name explaining by itself. Personally, I am
inclined to provide a path to the option and not a boolean.

> - When --search-file-paths is "auto", file paths are automatically
>   searched for against terms that contain a slash.  E.g. "lib" won't
>   return file paths but "lib/" will.

This should be cool.
With regexp too.

Time to time, I am looking for header C file or latex style but I do
not know the path. I would like to have something like:

  guix search gmsh.h
or
 guix search ieee*.sty


> Another feature that could be nice: list the file paths for the given
> packages.
> I think we need a separate subcommand for this, e.g. "guix list-files".

Yes, cool!


IMHO, it should be included under "guix package", i.e.,

  guix package gmsh --list-files

should returns something like:

--8<---------------cut here---------------start------------->8---
bin/gmsh
share/applications/gmsh.desktop
share/doc/gmsh/README.Debian
share/doc/gmsh/TODO.Debian
share/doc/gmsh/changelog.Debian.gz
share/doc/gmsh/changelog.gz
share/doc/gmsh/copyright
share/info/gmsh.info.gz
share/man/man1/gmsh.1.gz
share/pixmaps/gmsh_16x16.xpm
share/pixmaps/gmsh_32x32.xpm
--8<---------------cut here---------------end--------------->8---

(list from https://packages.debian.org/buster/amd64/gmsh/filelist)


All the best,
simon