From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Gibbons Subject: Re: Organizing packages Date: Mon, 15 Jul 2019 11:21:01 -0600 Message-ID: <20190715112101.5e83a861@gmail.com> References: <20190709100732.3f760245@gmail.com> <87ef2s4t8d.fsf@gnu.org> 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]:44092) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hn4f6-0002c0-3W for guix-devel@gnu.org; Mon, 15 Jul 2019 13:21:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hn4f4-0006Ic-NA for guix-devel@gnu.org; Mon, 15 Jul 2019 13:21:16 -0400 In-Reply-To: <87ef2s4t8d.fsf@gnu.org> 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: Ludovic =?UTF-8?B?Q291cnTDqHM=?= Cc: guix-devel@gnu.org On Sun, 14 Jul 2019 15:54:10 +0200 Ludovic Court=C3=A8s wrote: > 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: > > > > 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. =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 lists = all the > packages, to find out where the package you=E2=80=99re looking for lives. >=20 > I believe =E2=80=98guix edit=E2=80=99 greatly solves that (along with Hel= m 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. > > 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. =20 This was an afterthought. >=20 > I don=E2=80=99t think the module hierarchy should be thought of as a tool= for > users to search for packages. >=20 > So really, =E2=80=98guix search=E2=80=99 is the tool that should be impro= ved. It=E2=80=99s > 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. >=20 > What we can do is look at specific examples to see if there=E2=80=99s > something we can improve on the current scoring system (with the > understanding that sometimes the answer is that we cannot do any > better.) >=20 > For example, =E2=80=98guix search drawing program=E2=80=99 shows Tux Pain= t as the > first result, which is good; but =E2=80=98guix search drawing=E2=80=99 an= d =E2=80=98guix > search drawing application=E2=80=99 are much less useful. In this partic= ular > example, it=E2=80=99s not clear to me what can be done. >=20 > One suggestion that was made before and that might help here is to > increase the score of leaf packages (applications). >=20 > Food for thought! >=20 > Ludo=E2=80=99. 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