Re-approaching package tagging

Re-approaching package tagging

[Christopher Lemmer Webber]

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?

 - Chris

Re: Re-approaching package tagging

[swedebugia]

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?

-- 
Cheers Swedebugia

[1] I started the work lately with bindings here 
https://gitlab.com/swedebugia/guile-wikidata help is welcome!

Re: Re-approaching package tagging

[zimoun]

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

[Catonano]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

Il giorno lun 17 dic 2018 alle ore 22:10 swedebugia <swedebugia@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 ?

[-- Attachment #2: Type: text/html, Size: 3322 bytes --]

Re: Re-approaching package tagging

[Catonano]

[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]

Il giorno mar 18 dic 2018 alle ore 08:48 Catonano <catonano@gmail.com> ha
scritto:

>
>
> Il giorno lun 17 dic 2018 alle ore 22:10 swedebugia <swedebugia@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 ?
>


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/msg00000.html

[-- Attachment #2: Type: text/html, Size: 4082 bytes --]

Re: Re-approaching package tagging

[swedebugia]

On 2018-12-18 08:48, Catonano wrote:
> 
> 
> Il giorno lun 17 dic 2018 alle ore 22:10 swedebugia 
> <swedebugia@riseup.net <mailto:swedebugia@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

[swedebugia]

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 
>> <swedebugia@riseup.net <mailto:swedebugia@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 places when we have 
over half a million free software packages to juggle?

Here is a small comparison example:
Top 8 JS packages according to 
https://github.com/search?o=desc&q=js&s=stars&type=Repositories 
(900.000+ repositories in total!) (i filtered out a few non softwares)

1. angular.js
https://www.wikidata.org/wiki/Q28925578
https://directory.fsf.org/wiki/Angular2
2. node
https://directory.fsf.org/wiki/Node#tab=Overview
https://www.wikidata.org/wiki/Q756100
3. axios
not found in either
4. three.js
https://www.wikidata.org/wiki/Q3525922
https://directory.fsf.org/wiki/Three.js
5. socket.io
https://www.wikidata.org/wiki/Q7552998
not found (poor search function in my view)
6. reveal.js
not found
not found
7. chart.js
not found
not found
8. json-server
not found
not found

Wikidata already contains way more entries and data on the entries I 
compared (e.g. node, npm, gcc) than FSD despite it being a much younger 
project.

-- 
Cheers Swedebugia

Re: Re-approaching package tagging

[Ludovic Courtès]

Hello,

Christopher Lemmer Webber <cwebber@dustycloud.org> 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
> hyperrogue	10.5	out	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

[Christopher Lemmer Webber]

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

[zimoun]

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]

Hi,

zimoun <zimon.toutoune@gmail.com> 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

[zimoun]

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

[zimoun]

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

[Ludovic Courtès]

Hello,

zimoun <zimon.toutoune@gmail.com> 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

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> zimoun <zimon.toutoune@gmail.com> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Re-approaching package tagging

[Ludovic Courtès]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> 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

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hello,
>
> zimoun <zimon.toutoune@gmail.com> 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

[swedebugia]

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]

Hi,

Christopher Lemmer Webber <cwebber@dustycloud.org> 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

[Ludovic Courtès]

Christopher Lemmer Webber <cwebber@dustycloud.org> 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

[zimoun]

> 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

[Ludovic Courtès]

zimoun <zimon.toutoune@gmail.com> 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

[zimoun]

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