[MetaCPAN] GET-ing a module by name Case-Insensitively

Randy Stauner rwstauner at cpan.org
Sat Jun 20 18:19:14 GMT 2015


Yes, PAUSE allows case-sensitive conflicts, the trouble comes in that you
can't install conflicting modules on a case insensitive system
(Common::Sense and common::sense, for example).

Anyway...

In your search body I would change "match" to "term" since "status" is an
exact string match.

Additionally the filters in
https://github.com/CPAN-API/cpan-api/blob/master/lib/MetaCPAN/Document/File.pm#L860
should be used, as results can be incorrect without all of them.

So you'd want something like this:

{
  "filter": {
    "and": [
      { "term": { "module.name.lowercase": "lwp::useragent" } },
      { "term": { "status": "latest" } },
      { "term": { "file.indexed": true } },
      { "not":  { "term": { "file.authorized": false } } }
    ]
  },
  "fields": ["module", "author", "release"]
}

Note that you can use "fields" to get back just the values you're
interested in.

Unfortunately the issue you referred to with GET limitations is even worse
in this case.

I think the shortest thing you could do for GET would be:
curl '
api.metacpan.org/v0/module/?q=module.name.lowercase:lwp\%3A\%3Auseragent+AND+status:latest
'
(you can append "&fields=module,author,release" or similar if desired)

Note that you have to backslash escape the colons in the module name and
you need an uppercase AND before status:latest.

This is less efficient, however, since it is using a "querystring" query
instead of filters.  I cannot find documentation to suggest that it is
possible to use this shortcut syntax with filters.

It may be worth noting that the current "/v0/module/Mod::Name" api
additionally searches the "documentation" field to find files where the pod
is separate from the packages.  That field also has a lowercase-analyzed
field.  It then tries to choose the most relevant of the results.  I'm not
sure if that logic is relevant for your use case or not.

On Sat, Jun 20, 2015 at 8:18 AM, SundaraRaman R <sundaryourfriend at gmail.com>
wrote:

> Found the thread: http://www.perlmonks.org/?node_id=345472 . Looks
> like I was off by 9 years on the date.
>
> Running that script on the current 02packages.details.txt gives back
> 125 pairs now (compared to 44 as of 2004). But it does appear that,
> like someone on that thread mentions, many of these are changes
> between different versions of the same distribution, rather than
> outright conflicts, and would disappear if we chose only the latest
> version of each distribution to compare. I guess this might be an easy
> job now with MetaCPAN, but I lack the ElasticSearch wizardry to do
> this myself.
>
> On Sat, Jun 20, 2015 at 8:28 PM, SundaraRaman R
> <sundaryourfriend at gmail.com> wrote:
> > I looked into that, and found a Perlmonks thread from 2013 (I think)
> > where someone had written a script to find modules that differed only
> > by case, and found there were 44 such pairs back then (I'll post the
> > link to the thread when I manage to find it again). So, it appears
> > PAUSE does allow that.
> >
> > But in this case, that is an edge case that I think is okay to ignore
> > - I'm hoping that whatever the solution is, it will also tell us when
> > there is more than one match, so that in those ambiguous cases we can
> > avoid showing the user anything.
> >
> > -
> > Sundar
> >
>
> _______________________________________________
> MetaCPAN mailing list
> MetaCPAN at lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/metacpan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/metacpan/attachments/20150620/1770db34/attachment-0001.htm>


More information about the MetaCPAN mailing list