Re: Re-approaching package tagging
Hi Chris,
Chris Marusich skribis:
> Is "guix package --search" case-insensitive? The manual ((guix)
> Invoking guix package) does not seem to mention it.
Per guix/scripts/package.scm, it is case-insensitive:
--8<---cut here---start->8---
(('search _)
(let* ((patterns (filter-map (match-lambda
(('query 'search rx) rx)
(_ #f))
opts))
(regexps (map (cut make-regexp* <> regexp/icase) patterns)))
--8<---cut here---end--->8---
I’ll add a note in the manual.
Ludo’.
Re: Re-approaching package tagging
Hi, Christopher Lemmer Webber skribis: > I wonder for keywords that would be awkward to "force" into the > description if we could have an "extra keywords" section? Then we can > skip tagging, but in case a package's description didn't comfortably fit > that word, you can still find it by it. Then it's not separate tagging, > just extra words to find a package by that the description didn't say. Good question. I don’t think we’ve really had concerns about “extra words” in the past (and the regexps are also matched against the file name for instance, which can also help), but let’s keep that suggestion in mind if that happens! Ludo’.
Re: Re-approaching package tagging
Hi Ludo, > Is there anything specific that you think could be borrowed from > aptitude in the current Guix framework? Once the recutils doc carefully read, all the features from aptitude that I use are already in recutils. :-) Even, the option -e seems more powerful. Something maybe useful should be to able to search if the binary is already in the store or not. Other thing is the option `-F %O' from aptitude which shows the origin of the package. I do not have my mind clear about the channels--I am discovering them--but basically I am doing some `git grep' which is not the most friendly. Or I miss a point. Is it possible to remove the first double quote when searching for all the packages? guix package -s "" | recsel -C -e 'name ~ "agda"' -p synopsis e.g guix package -s | recsel -C -e 'name ~ "agda"' -p synopsis In the long term, I find more convenient something is this flavor: guix package --search='name ~ "agda" && !(name ~ "mode") -p synopsis' I mean avoid the pipe. But it is bikeshedding, isn't it? :-) Last, recutils is not installed by default with Guix. Why not? Maybe with a curated list of dependencies. Hope it makes sense. All the best, simon
Re: Re-approaching package tagging
On 2018-12-20 11:57, Christopher Lemmer Webber wrote: snip I wonder for keywords that would be awkward to "force" into the description if we could have an "extra keywords" section? Then we can skip tagging, but in case a package's description didn't comfortably fit that word, you can still find it by it. Then it's not separate tagging, just extra words to find a package by that the description didn't say. WDYT? I like it. We could upstream those also to wikidata where they could be used as basis for categorization of software. -- Cheers Swedebugia
Re: Re-approaching package tagging
Ludovic Courtès writes: > Hello, > > zimoun skribis: > >>> And how the regexp works ? >>> I am not able to find some doc... I am diving in the code but it is >>> not easy to find. :-) >> >> If I understand well, basically the code is here, right? >> http://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/package.scm#n754 >> >> And the regexp engine comes from the module (ice-9 regex), right? >> Documented there: >> https://www.gnu.org/software/guile/manual/html_node/Regular-Expressions.html#Regular-Expressions > > Yes, just plain POSIX regexps. > >>> For example, how to search package with the name emacs and not the name >>> emacs- >>> or how to search package with the name emacs and with the decription GNU? >>> The '-s foo -s bar' is OR. What about the AND? >>> etc. >> >> This needs more than the actual implementation, right? > > Having multiple -s flags makes it an “or” but it influences the > relevance score: > > > https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-package.html#index-searching-for-packages > > So if you take the results with the highest score, that’ll probably be > those that match all the regexps. > > HTH! > > Ludo’. I wonder for keywords that would be awkward to "force" into the description if we could have an "extra keywords" section? Then we can skip tagging, but in case a package's description didn't comfortably fit that word, you can still find it by it. Then it's not separate tagging, just extra words to find a package by that the description didn't say. WDYT?
Re: Re-approaching package tagging
Ludovic Courtès writes: > Hello, > > zimoun skribis: > >>> And how the regexp works ? >>> I am not able to find some doc... I am diving in the code but it is >>> not easy to find. :-) >> >> If I understand well, basically the code is here, right? >> http://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/package.scm#n754 >> >> And the regexp engine comes from the module (ice-9 regex), right? >> Documented there: >> https://www.gnu.org/software/guile/manual/html_node/Regular-Expressions.html#Regular-Expressions > > Yes, just plain POSIX regexps. Is "guix package --search" case-insensitive? The manual ((guix) Invoking guix package) does not seem to mention it. I think this feature is great, by the way! I use it all the time. -- Chris signature.asc Description: PGP signature
Re: Re-approaching package tagging
zimoun skribis: >> Ah ha! :-) Now the question is whether this is a convenient and >> efficient way to search for packages. > > As an happy user of Debian, I like the aptitude way convenient and > efficient to search packages. > https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html This is quite different from what we have, and not everything is applicable I guess. Is there anything specific that you think could be borrowed from aptitude in the current Guix framework? Thanks, Ludo’.
Re: Re-approaching package tagging
Hello, zimoun skribis: >> And how the regexp works ? >> I am not able to find some doc... I am diving in the code but it is >> not easy to find. :-) > > If I understand well, basically the code is here, right? > http://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/package.scm#n754 > > And the regexp engine comes from the module (ice-9 regex), right? > Documented there: > https://www.gnu.org/software/guile/manual/html_node/Regular-Expressions.html#Regular-Expressions Yes, just plain POSIX regexps. >> For example, how to search package with the name emacs and not the name >> emacs- >> or how to search package with the name emacs and with the decription GNU? >> The '-s foo -s bar' is OR. What about the AND? >> etc. > > This needs more than the actual implementation, right? Having multiple -s flags makes it an “or” but it influences the relevance score: https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-package.html#index-searching-for-packages So if you take the results with the highest score, that’ll probably be those that match all the regexps. HTH! Ludo’.
Re: Re-approaching package tagging
Hi, I partially answer to myself. ;-) > And how the regexp works ? > I am not able to find some doc... I am diving in the code but it is > not easy to find. :-) If I understand well, basically the code is here, right? http://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/package.scm#n754 And the regexp engine comes from the module (ice-9 regex), right? Documented there: https://www.gnu.org/software/guile/manual/html_node/Regular-Expressions.html#Regular-Expressions > For example, how to search package with the name emacs and not the name emacs- > or how to search package with the name emacs and with the decription GNU? > The '-s foo -s bar' is OR. What about the AND? > etc. This needs more than the actual implementation, right? Thank you and sorry if I am slow to understand. All the best, simon
Re: Re-approaching package tagging
> Ah ha! :-) Now the question is whether this is a convenient and > efficient way to search for packages. As an happy user of Debian, I like the aptitude way convenient and efficient to search packages. https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html What do you think? All the best, simon
Re: Re-approaching package tagging
Hi, Wow! Thank you! :-) And how the regexp works ? I am not able to find some doc... I am diving in the code but it is not easy to find. :-) Well, is regexp a real regular expression? For example, how to search package with the name emacs and not the name emacs-*? or how to search package with the name emacs and with the decription GNU? The '-s foo -s bar' is OR. What about the AND? etc. Thank you in advance for any pointer. All the best, simon
Re: Re-approaching package tagging
Christopher Lemmer Webber skribis: > I'm embarassed to say I didn't know about --search :) Ah ha! :-) Now the question is whether this is a convenient and efficient way to search for packages. Ludo’.
Re: Re-approaching package tagging
Hi, zimoun skribis: > How the relevance is evaluated ? > And how the regexp works ? Roughly relevance is computed as a function of the number of regexp matches and the location of those matches (package name, synopsis, description): https://git.savannah.gnu.org/cgit/guix.git/tree/guix/ui.scm#n1284 HTH! Ludo’.
Re: Re-approaching package tagging
On 2018-12-19 07:51, swedebugia wrote: On 2018-12-18 08:48, Catonano wrote: Il giorno lun 17 dic 2018 alle ore 22:10 swedebugia mailto:swedebu...@riseup.net>> ha scritto: Hi :) On 2018-12-17 20:01, Christopher Lemmer Webber wrote: > Hello, > > In the past when we've discussed package tagging, I think Ludo' has been > against it, primarily because it's a giant source of bikeshedding. I > agree that it's a huge space for bikeshedding... no space provides more > bikeshedding than naming things, and tagging things is a many to many > naming system. > > However, I will say that finding packages based on topical interest is > pretty hard right now. If I want to find all the available roguelikes: > > cwebber@jasmine:~$ guix package -A rogue > hyperrogue 10.5 out gnu/packages/games.scm:3652:2 > roguebox-adventures 2.2.1 out gnu/packages/games.scm:1047:2 > > Hm, that's strange, there's definitely more roguelikes that should show > up than that! A more specific search is even worse: > > cwebber@jasmine:~$ guix package -A roguelike > cwebber@jasmine:~$ > > What I should have gotten back: > - angband > - cataclysm-dda > - crawl > - crawl-tiles > - hyperrogue > - nethack > - roguebox-adventures > - tome4 > > So I only got 1/4 of the entries I was interested in in my first query. > Too bad! > > I get that we're opening up space for bikeshedding and *that's true*. > But it seems like not doing so makes things hard on users. > > What do you think? Is there a way to open the (pandora's?) box of tags > safely? Yes and no. Pjotr and I have discussed this relating to biotech software. He said that many scientists have a hard time finding the right tools for the job. I proposed tight integration with wikidata[1] (every software in the world will eventually have an item there) and Guix (QID on every package and lookup/catogory integration) and leave all the categorizing to them. Ha problem sidestepped, they are bikeshedding experts over there in wikiland! :D The advantage of this is that everyone using wikidata (every package manager) could pull the same categorization so we only do it once in a central What do you think? -- There is also the Free Software Directory https://directory.fsf.org/wiki/Main_Page I don't know what the relationship between Wikidata and the FSD is Does Wikidata import data from the FSD ? Or viceversa ? I don't know. For now at least they keep reference to the FSD on software-entries that exists in the FSD. We could integrate the FSD also but I have yet to investigate if they provide an API for their entries. Anyways I view FSD as a subset of Wikidata/Wikipedia. Wikidata is the node and FSD the leaf. Wikidata/Wikipedia will probably within a few years contain the data or links to the data that now exists in the FSD. Correct me if I'm wrong but the only advantage of FSD over Wikidata & Wikipedia is that they do not include references to proprietary software at all. In my view it is more feasible to compile the information on in a structured way in central node and then pull the relevant bits to the leaf. E.g. FSD of the future could be generated from all wikidata-entries and extracts of wikipedia that are an instance of https://www.wikidata.org/wiki/Q341. This would avoid fragmentation and help concentrate on building a large shared collective source of all knowledge within the wiki-community. FSD could exist anyhow and surely help enrich the upstream data. Similarly we could generate a wikipedia subset without any entries pointing to (evil) private corporations (any entries that is part of https://www.wikidata.org/wiki/Q5621421 or whatever). I can't imagine what this would be good for but it its possible. I cannot imagine that the information in FSD would not be accepted in any of the wikimedia projects. I could be wrong though as I honestly did not visit or study the FSD very much. Also the license of the FSD (GFDL 1.2) differs from both Wikidata (CC0) and Wikipedia (CC-BY-SA 4.0 + GFDL 1.2). This is not to their advantage in the long run. I fear the FSD is already becoming unmaintained and obsolete with people favoring more open and smarter solutions from the wikimedia-projects (at least I am). When it comes to completeness we have at least 500.000 packages missing in both Wikidata and FSD (450.000+ MIT & CC0 licensed npm packages). Would any of you like to import those twice? I don't and as I see it Wikidata is far superior in multiple ways to get the job done and do it well with a big community backing it up with tools, bots, manual edits, et all. Who wants to update with new versions in two
Re: Re-approaching package tagging
On 2018-12-18 08:48, Catonano wrote: Il giorno lun 17 dic 2018 alle ore 22:10 swedebugia mailto:swedebu...@riseup.net>> ha scritto: Hi :) On 2018-12-17 20:01, Christopher Lemmer Webber wrote: > Hello, > > In the past when we've discussed package tagging, I think Ludo' has been > against it, primarily because it's a giant source of bikeshedding. I > agree that it's a huge space for bikeshedding... no space provides more > bikeshedding than naming things, and tagging things is a many to many > naming system. > > However, I will say that finding packages based on topical interest is > pretty hard right now. If I want to find all the available roguelikes: > > cwebber@jasmine:~$ guix package -A rogue > hyperrogue 10.5 out gnu/packages/games.scm:3652:2 > roguebox-adventures 2.2.1 out gnu/packages/games.scm:1047:2 > > Hm, that's strange, there's definitely more roguelikes that should show > up than that! A more specific search is even worse: > > cwebber@jasmine:~$ guix package -A roguelike > cwebber@jasmine:~$ > > What I should have gotten back: > - angband > - cataclysm-dda > - crawl > - crawl-tiles > - hyperrogue > - nethack > - roguebox-adventures > - tome4 > > So I only got 1/4 of the entries I was interested in in my first query. > Too bad! > > I get that we're opening up space for bikeshedding and *that's true*. > But it seems like not doing so makes things hard on users. > > What do you think? Is there a way to open the (pandora's?) box of tags > safely? Yes and no. Pjotr and I have discussed this relating to biotech software. He said that many scientists have a hard time finding the right tools for the job. I proposed tight integration with wikidata[1] (every software in the world will eventually have an item there) and Guix (QID on every package and lookup/catogory integration) and leave all the categorizing to them. Ha problem sidestepped, they are bikeshedding experts over there in wikiland! :D The advantage of this is that everyone using wikidata (every package manager) could pull the same categorization so we only do it once in a central What do you think? -- There is also the Free Software Directory https://directory.fsf.org/wiki/Main_Page I don't know what the relationship between Wikidata and the FSD is Does Wikidata import data from the FSD ? Or viceversa ? I don't know. For now at least they keep reference to the FSD on software-entries that exists in the FSD. We could integrate the FSD also but I have yet to investigate if they provide an API for their entries. Anyways I view FSD as a subset of Wikidata/Wikipedia. Wikidata is the node and FSD the leaf. Wikidata/Wikipedia will probably within a few years contain the data or links to the data that now exists in the FSD. Correct me if I'm wrong but the only advantage of FSD over Wikidata & Wikipedia is that they do not include references to proprietary software at all. In my view it is more feasible to compile the information on in a structured way in central node and then pull the relevant bits to the leaf. E.g. FSD of the future could be generated from all wikidata-entries and extracts of wikipedia that are an instance of https://www.wikidata.org/wiki/Q341. This would avoid fragmentation and help concentrate on building a large shared collective source of all knowledge within the wiki-community. FSD could exist anyhow and surely help enrich the upstream data. Similarly we could generate a wikipedia subset without any entries pointing to (evil) private corporations (any entries that is part of https://www.wikidata.org/wiki/Q5621421 or whatever). I can't imagine what this would be good for but it its possible. I cannot imagine that the information in FSD would not be accepted in any of the wikimedia projects. I could be wrong though as I honestly did not visit or study the FSD very much. -- Cheers Swedebugia
Re: Re-approaching package tagging
Dear, How the relevance is evaluated ? And how the regexp works ? Maybe, I miss the documentation in the manual. I share the same feeling as Ludo about debtags. What do you think about `aptitude search` User Interface? https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html Thank you in advance for any pointer. All the best, simon
Re: Re-approaching package tagging
Ludovic Courtès writes: > I’m surprised you don’t mention --search, which is more appropriate than > -A (‘-A’ is here only to search among package names): > > --8<---cut here---start->8--- > $ guix package -s roguelike | recsel -p name,relevance > name: roguebox-adventures > relevance: 7 > > name: tome4 > relevance: 5 > > name: crawl > relevance: 5 > > name: crawl-tiles > relevance: 5 > > name: cataclysm-dda > relevance: 5 > > name: angband > relevance: 5 > --8<---cut here---end--->8--- > > I’m very much in favor of improving ‘--search’ until we’re happy with > the results it gives. > > WDYT? > > Ludo’. I'm embarassed to say I didn't know about --search :)
Re: Re-approaching package tagging
Il giorno mar 18 dic 2018 alle ore 08:48 Catonano ha scritto: > > > Il giorno lun 17 dic 2018 alle ore 22:10 swedebugia > ha scritto: > >> Hi :) >> >> On 2018-12-17 20:01, Christopher Lemmer Webber wrote: >> > Hello, >> > >> > In the past when we've discussed package tagging, I think Ludo' has been >> > against it, primarily because it's a giant source of bikeshedding. I >> > agree that it's a huge space for bikeshedding... no space provides more >> > bikeshedding than naming things, and tagging things is a many to many >> > naming system. >> > >> > However, I will say that finding packages based on topical interest is >> > pretty hard right now. If I want to find all the available roguelikes: >> > >> > cwebber@jasmine:~$ guix package -A rogue >> > hyperrogue10.5out gnu/packages/games.scm:3652:2 >> > roguebox-adventures 2.2.1 out gnu/packages/games.scm:1047:2 >> > >> > Hm, that's strange, there's definitely more roguelikes that should show >> > up than that! A more specific search is even worse: >> > >> > cwebber@jasmine:~$ guix package -A roguelike >> > cwebber@jasmine:~$ >> > >> > What I should have gotten back: >> > - angband >> > - cataclysm-dda >> > - crawl >> > - crawl-tiles >> > - hyperrogue >> > - nethack >> > - roguebox-adventures >> > - tome4 >> > >> > So I only got 1/4 of the entries I was interested in in my first query. >> > Too bad! >> > >> > I get that we're opening up space for bikeshedding and *that's true*. >> > But it seems like not doing so makes things hard on users. >> > >> > What do you think? Is there a way to open the (pandora's?) box of tags >> > safely? >> >> Yes and no. >> >> Pjotr and I have discussed this relating to biotech software. He said >> that many scientists have a hard time finding the right tools for the job. >> >> I proposed tight integration with wikidata[1] (every software in the >> world will eventually have an item there) and Guix (QID on every package >> and lookup/catogory integration) and leave all the categorizing to them. >> Ha problem sidestepped, they are bikeshedding experts over there in >> wikiland! :D >> >> The advantage of this is that everyone using wikidata (every package >> manager) could pull the same categorization so we only do it once in a >> central >> >> What do you think? >> >> -- >> >> > > There is also the Free Software Directory > https://directory.fsf.org/wiki/Main_Page > > I don't know what the relationship between Wikidata and the FSD is > > Does Wikidata import data from the FSD ? Or viceversa ? > There happens to be this thread on their mailing list, I think it's relevant (the whole thread is interesting) https://lists.gnu.org/archive/html/directory-discuss/2018-11/msg0.html
Re: Re-approaching package tagging
Hello, Christopher Lemmer Webber skribis: > In the past when we've discussed package tagging, I think Ludo' has been > against it, primarily because it's a giant source of bikeshedding. I > agree that it's a huge space for bikeshedding... no space provides more > bikeshedding than naming things, and tagging things is a many to many > naming system. The reason I’m unconvinced about tags is that I used to be a big fan of them, back when debtags was introduced (long ago!), but then I had to face reality: people (me included) would just do plain text searches, not sophisticated tag queries. > However, I will say that finding packages based on topical interest is > pretty hard right now. If I want to find all the available roguelikes: > > cwebber@jasmine:~$ guix package -A rogue > hyperrogue10.5out gnu/packages/games.scm:3652:2 > roguebox-adventures 2.2.1 out gnu/packages/games.scm:1047:2 I’m surprised you don’t mention --search, which is more appropriate than -A (‘-A’ is here only to search among package names): --8<---cut here---start->8--- $ guix package -s roguelike | recsel -p name,relevance name: roguebox-adventures relevance: 7 name: tome4 relevance: 5 name: crawl relevance: 5 name: crawl-tiles relevance: 5 name: cataclysm-dda relevance: 5 name: angband relevance: 5 --8<---cut here---end--->8--- I’m very much in favor of improving ‘--search’ until we’re happy with the results it gives. WDYT? Ludo’.
Re: Re-approaching package tagging
Il giorno lun 17 dic 2018 alle ore 22:10 swedebugia ha scritto: > Hi :) > > On 2018-12-17 20:01, Christopher Lemmer Webber wrote: > > Hello, > > > > In the past when we've discussed package tagging, I think Ludo' has been > > against it, primarily because it's a giant source of bikeshedding. I > > agree that it's a huge space for bikeshedding... no space provides more > > bikeshedding than naming things, and tagging things is a many to many > > naming system. > > > > However, I will say that finding packages based on topical interest is > > pretty hard right now. If I want to find all the available roguelikes: > > > > cwebber@jasmine:~$ guix package -A rogue > > hyperrogue10.5out gnu/packages/games.scm:3652:2 > > roguebox-adventures 2.2.1 out gnu/packages/games.scm:1047:2 > > > > Hm, that's strange, there's definitely more roguelikes that should show > > up than that! A more specific search is even worse: > > > > cwebber@jasmine:~$ guix package -A roguelike > > cwebber@jasmine:~$ > > > > What I should have gotten back: > > - angband > > - cataclysm-dda > > - crawl > > - crawl-tiles > > - hyperrogue > > - nethack > > - roguebox-adventures > > - tome4 > > > > So I only got 1/4 of the entries I was interested in in my first query. > > Too bad! > > > > I get that we're opening up space for bikeshedding and *that's true*. > > But it seems like not doing so makes things hard on users. > > > > What do you think? Is there a way to open the (pandora's?) box of tags > > safely? > > Yes and no. > > Pjotr and I have discussed this relating to biotech software. He said > that many scientists have a hard time finding the right tools for the job. > > I proposed tight integration with wikidata[1] (every software in the > world will eventually have an item there) and Guix (QID on every package > and lookup/catogory integration) and leave all the categorizing to them. > Ha problem sidestepped, they are bikeshedding experts over there in > wikiland! :D > > The advantage of this is that everyone using wikidata (every package > manager) could pull the same categorization so we only do it once in a > central > > What do you think? > > -- > > There is also the Free Software Directory https://directory.fsf.org/wiki/Main_Page I don't know what the relationship between Wikidata and the FSD is Does Wikidata import data from the FSD ? Or viceversa ?
Re: Re-approaching package tagging
Dear, Does the command `guix package -s rogue` fit your needs ? Because `--search` search in synopsis and description. Then `ruby-multi-test` is false-positive, I guess. And `nethack` does not show up. Maybe because the description and/or synopsis is not verbose enough. If `guix package -s rogue -s dungeon | recsel -C -p name` then more package are found. Do they correspond? e.g., powwow? What is the feedback about the Debian tagging system debtags? I mean that I am an happy user of Debian and I do not use so much debtags. Because I do not often explore packages and so I find the `aptitude search` regexp then grep easier to remember. Well, other said, from my point of view, a tag system does not solve the issue here and it adds layer (bikeshedding?). The easiest fix seems to improve the descriptions field. IMHO. Or to add features to --search and regexp. In complement to the more elegant solution proposed by swedebugia. What do you think? All the best, simon
Re: Re-approaching package tagging
Hi :) On 2018-12-17 20:01, Christopher Lemmer Webber wrote: Hello, In the past when we've discussed package tagging, I think Ludo' has been against it, primarily because it's a giant source of bikeshedding. I agree that it's a huge space for bikeshedding... no space provides more bikeshedding than naming things, and tagging things is a many to many naming system. However, I will say that finding packages based on topical interest is pretty hard right now. If I want to find all the available roguelikes: cwebber@jasmine:~$ guix package -A rogue hyperrogue 10.5out gnu/packages/games.scm:3652:2 roguebox-adventures 2.2.1 out gnu/packages/games.scm:1047:2 Hm, that's strange, there's definitely more roguelikes that should show up than that! A more specific search is even worse: cwebber@jasmine:~$ guix package -A roguelike cwebber@jasmine:~$ What I should have gotten back: - angband - cataclysm-dda - crawl - crawl-tiles - hyperrogue - nethack - roguebox-adventures - tome4 So I only got 1/4 of the entries I was interested in in my first query. Too bad! I get that we're opening up space for bikeshedding and *that's true*. But it seems like not doing so makes things hard on users. What do you think? Is there a way to open the (pandora's?) box of tags safely? Yes and no. Pjotr and I have discussed this relating to biotech software. He said that many scientists have a hard time finding the right tools for the job. I proposed tight integration with wikidata[1] (every software in the world will eventually have an item there) and Guix (QID on every package and lookup/catogory integration) and leave all the categorizing to them. Ha problem sidestepped, they are bikeshedding experts over there in wikiland! :D The advantage of this is that everyone using wikidata (every package manager) could pull the same categorization so we only do it once in a central What do you think? -- Cheers Swedebugia [1] I started the work lately with bindings here https://gitlab.com/swedebugia/guile-wikidata help is welcome!
