On Mon, 15 Jul 2019 19:38:34 +0200
Robert Vollmert <r...@vllmrt.net> wrote:
> > On 15. Jul 2019, at 19:21, Jesse Gibbons <jgibbons2...@gmail.com>
> > wrote:
> >
> > On Sun, 14 Jul 2019 15:54:10 +0200
> > Ludovic Courtès <l...@gnu.org> wrote:
> >
> >> Hello!
> >>
> >> Jesse Gibbons <jgibbons2...@gmail.com> 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.
>
> Just to voice some support for a consistent approach. It would be
> beneficial in a similar way that a consistent indentation style
> helps: Less decisions to make, less opportunity for bike-shedding
> discussions.
>
> (Personally, one file per package sounds fine, too. No confusion
> about why which module imports what. No overhead deciding where to
> file a package. No need to grep around for where a package might be
> defined.)
>
I too wouldn't mind a one-package-per-file approach as long as it is
consistent. But consider packages that have multiple parts like gcc and
texlive, as well as the dictionaries packages that are generated with
non-public syntax like the french dictionaries in libreoffice.scm, not
to mention the packages for both python2 and python3. I think there's a
good reason to cluster them into groups. But the one-package-per-file
approach would affect guix search in a significant negative way, as I
pointed out unless something is done to change how guix search works.
