Re: Organizing packages

[Robert Vollmert]

> On 15. Jul 2019, at 19:21, Jesse Gibbons <address@hidden> wrote:
> 
> 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.

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.)