[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Organizing packages
From: |
Jesse Gibbons |
Subject: |
Re: Organizing packages |
Date: |
Mon, 15 Jul 2019 11:21:01 -0600 |
On Sun, 14 Jul 2019 15:54:10 +0200
Ludovic Courtès <address@hidden> wrote:
> 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.)
>
Interesting. So is it worth trying to organize the guix packages or do
you think it will get too complicated? I'm primarily bothered by the
number of small files with only one package definition and the
inconsistency in how packages are organized. I would rather a file have
multiple package definitions that make sense together than a hundred
files with only one package definition.
> > 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.
This was an afterthought.
>
> 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.)
I was thinking this would help `guix search`. For example, if I try
`guix search game` a lot of the leaf packages in games.scm are ranked
with relevance level 1 because they do not have the word "game" in
their synopsis or description. I would expect them to have a higher
relevance (8 at the very minimum) because of their placement in
games.scm. I do not think these packages would be listed at all if they
were not in games.scm.
Hypothetically, if someone decided to define a package for the tuxemon
RPG in a new file "tuxemon.scm" and did not mention the word "game" in
the summary or description, it would not be listed in the `guix search
game` results at all. If it was placed into games.scm, then it would at
least come up in the results.
>
> 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’.
I have ideas about how to resolve this and other issues regarding `guix
search`, but perhaps they are best explained in bug reports or other
guix-devel discussions.
-Jesse