From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Gibbons Subject: Re: Organizing packages Date: Mon, 15 Jul 2019 14:15:41 -0600 Message-ID: <20190715141541.295d4e5d@gmail.com> References: <20190709100732.3f760245@gmail.com> <87ef2s4t8d.fsf@gnu.org> <20190715112101.5e83a861@gmail.com> <7D129B4F-4AA5-4626-94F3-EF070D316871@vllmrt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:54476) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hn7O4-0003sg-AV for guix-devel@gnu.org; Mon, 15 Jul 2019 16:15:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hn7O3-0003sc-1O for guix-devel@gnu.org; Mon, 15 Jul 2019 16:15:52 -0400 In-Reply-To: <7D129B4F-4AA5-4626-94F3-EF070D316871@vllmrt.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Robert Vollmert Cc: guix-devel@gnu.org On Mon, 15 Jul 2019 19:38:34 +0200 Robert Vollmert wrote: > > On 15. Jul 2019, at 19:21, Jesse Gibbons > > wrote: > >=20 > > On Sun, 14 Jul 2019 15:54:10 +0200 > > Ludovic Court=C3=A8s wrote: > > =20 > >> Hello! > >>=20 > >> Jesse Gibbons skribis: > >> =20 > >>> 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: > >>>=20 > >>> 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. > >>>=20 > >>> 2. If the package defines a compiler or interpreter for a language > >>> $LANG, it may go into ${LANG}.scm > >>>=20 > >>> 3. If the package is part of a large divisible project $PROJ like > >>> gcc or texlive, it may go into ${PROJ}.scm > >>>=20 > >>> 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 > >>>=20 > >>> 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. =20 > >>=20 > >> I had experience with Nixpkgs, which has a decision tree for where > >> to put packages: > >>=20 > >> https://nixos.org/nixpkgs/manual/#sec-hierarchy > >>=20 > >> In the end I didn=E2=80=99t find it to be helpful in any way: you=E2= =80=99d always > >> have to open =E2=80=98top-level/all-packages=E2=80=99, a file that lis= ts all the > >> packages, to find out where the package you=E2=80=99re looking for liv= es. > >>=20 > >> I believe =E2=80=98guix edit=E2=80=99 greatly solves that (along with = Helm or > >> similar editor support for grepping.) > >> =20 > > 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. =20 >=20 > 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. >=20 > (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.) >=20 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.