Re: Organizing packages

[Ludovic Courtès]

Hello!

Jesse Gibbons <address@hidden> skribis:

> I noticed that a few files have only one package definition and are
> named for that package. I think these packages can be organized better.
> Might I suggest the following rules:
>
> 1. if a package is a library for a particular language $LANG (like
> Python, Perl, etc.) it goes in ${LANG}-xyz.scm. If it is a library built
> for a particular PURPOSE, it may go into LANG-PURPOSE.scm with those
> packages.
>
> 2. If the package defines a compiler or interpreter for a language
> $LANG, it may go into ${LANG}.scm
>
> 3. If the package is part of a large divisible project $PROJ like gcc or
> texlive, it may go into ${PROJ}.scm
>
> 4. If the package is maintained a part of a large desktop environment
> $DE like GNOME or KDE, it may be put in ${DE}.scm
>
> 5. When in doubt, the package must go into a file named after its
> $PURPOSE, ${PURPOSE}.scm. For example, if the package is a game (like
> supertuxracer), it goes into games.scm; if it is for undirected
> fun (like sl), it goes into toys.scm; if it is for audio
> control or audio production, it goes into audio.scm; if it is for
> drawing or producing graphics, it goes into graphics.scm; etc. Projects
> that can be described with multiple purposes (like fortune) may go into
> any of those files.

I had experience with Nixpkgs, which has a decision tree for where to
put packages:

  https://nixos.org/nixpkgs/manual/#sec-hierarchy

In the end I didn’t find it to be helpful in any way: you’d always have
to open ‘top-level/all-packages’, a file that lists all the packages, to
find out where the package you’re looking for lives.

I believe ‘guix edit’ greatly solves that (along with Helm or similar
editor support for grepping.)

> I think this will make searching easier because not everything has an
> obvious name, and when I `guix search` for a purpose (like drawing) I
> often get unrelated results.

I don’t think the module hierarchy should be thought of as a tool for
users to search for packages.

So really, ‘guix search’ is the tool that should be improved.  It’s been
discussed many times, and improving it turns out to be difficult without
resorting to external sources of information (e.g., list of command
names, popularity database, etc.)

What we can do is look at specific examples to see if there’s something
we can improve on the current scoring system (with the understanding
that sometimes the answer is that we cannot do any better.)

For example, ‘guix search drawing program’ shows Tux Paint as the first
result, which is good; but ‘guix search drawing’ and ‘guix search
drawing application’ are much less useful.  In this particular example,
it’s not clear to me what can be done.

One suggestion that was made before and that might help here is to
increase the score of leaf packages (applications).

Food for thought!

Ludo’.