Type-based searches à la search.cpan.org

[joelbernstein]

s.c.o allows querying by "type" (module, distribution, author) which restricts results to only come from the specified type of resource.
I find this a very useful feature and have a number of browser quicksearches which rely on it.
I can't figure out how to achieve the same thing using metacpan.

Examples:

1. search for distributions matching DBIx::Class, without listing modules therein
2. search for modules matching DBIx::Class, ignoring which dist they are in
3. search for ACME as an author, ignoring any Acme:: modules
4. search for Acme modules, ignoring an author whose name contains 'acme'

[ranguard]

No action has happened - Closing as part of the great issue cull of Dec 2013

[ranguard]

Moving to wishlist: https://github.com/CPAN-API/cpan-api/wiki/Wishlist

[neilb]

Was about to submit an issue on this topic, then found this ticket via the wishlist. I often wish that MetaCPAN had the ability to constrain searches to distributions. It's the main case where I "go back" to using search.cpan.org

I think a drop-down menu is too "expensive": too much additional cognitive load for something I suspect many users wouldn't use.

Search operators (c.f. google's site:) would be handy, but might cause confusion due to the who colon thing:

dist: constant

[rwstauner]

I thought we had this (author: and distribution: operators)

[neilb]

I read your response: "yay!", quick, let's go and try it. I'll be embarrassed if it's there. Oh why didn't I know about this. Must read the doc. Is there doc?

oh, it doesn't work. Phew. And disappointed.

you're just playing with me, aren't you?

[rwstauner]

I know there is code to that effect in the Search controller, but if it
doesn't work as you expect I'll have to look at it later.

[oalders]

https://metacpan.org/search?q=author%3ANEILB
https://metacpan.org/search?q=author%3AOALDERS+HTML
https://metacpan.org/search?q=distribution%3AMoose+MOP

As I understand it, some Lucene syntax is exposed via ElasticSearch and that's what you are taking advantage of with the single colon. It's entirely undocumented, but something that we could reference via a small "advanced" link under the search box or something like that.

[neilb]

Nice tag-teaming for the double embarrassment there. Bastards.

I swear I was typing that last night and getting blank results. You sure you haven't just enabled that? ;-)

Nice though. I can type version:0.01 to find first releases of modules, and will have to think about other uses.

I'll have a go at writing an advanced help page, if you like?

[monken]

See http://lucene.apache.org/core/4_1_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html for the syntax and here is the mapping of the available fields for search: http://api.metacpan.org/v0/file/_mapping

Thanks for your help!

[omega]

Just a small input. We have that really "wasted" sidebar on the search results page, so perhaps addings links for "distrubution", "module", "author" facets or what you want to call them could be worth it as well?

[oiami]

How about something like we have other types of result in separate tabs e.g. distributions, modules and authors ? It will look like

I mixed all of your suggestions on this, any comment ?

[neilb]

@oiami: I like the idea! You could put the number of hits with each as well. Ie

All     |     Distributions (4)     |    Modules (16)    |    Authors (2)    |

It would be nice to compact the space taken up before you get to the actual search results. I don't have any immediate suggestion, but will have a think about that.

Also, I wonder could you drop the "All" tab, and only show the different types, picking "the most appropriate one" to display first?

[oiami]

As my experience, displaying result number in each tab is expensive, since sometime we have to send multi-query to get to total number of each type without displaying it.

I agree with the the space with since it's just mock up and it need more decoration :D

I'm not sure if it's good idea the drop 'All' tab, I think it's it can be the best choice for people who like something 'All in One', since it display many types of search results. Let listen what others say.

[rwstauner]

That's a very interesting idea (and a nice mock-up).
I'd like to gather more feedback before we go ahead with this.

I definitely agree with keeping the "All" results as the default. We have a few other issues out there where guessing has gotten us into trouble.

@oiami I appreciate your caution about getting the counts. I agree with you and don't want to add new queries just for that. However, in this case we may already be doing those queries and it might just be a matter of adding up the totals for the the collapsed distribution (the default) search. If that info is already available we can definitely use it. If not the counts can wait.

I'd also like to better define what each of those searches (tabs) would be in order to make sure it's useful. My first thought was that we already have all the results and these would basically be display filters. Then I realized that the distribution: search operator is only for exact matches (the default field is not_analyzed), so it might be nice to give people a clickable link rather than expecting them to know that they have to type in distribution.analyzed: to get that to work. Then again, if PAUSE moves to requiring a dist name to match a module name (which is the overwhelming majority now anyway) there may not be much use in a distribution name search.

The modules search (tab) would be essentially the same as "all" minus the authors, though I suppose it could display the "expanded" style (instead of the collapsed by distribution style).

The authors tab would just show all authors (whereas the ones on top of the "all" tab might be clipped)?

I'm not sure about some of those things yet, so like I said, let's gather some more feedback and give this some more thought. It could be a great addition.