Idea: Use An API Rather Than A Static Index File

[thaljef]

I would like to install modules from an arbitrary repository without having to fetch an index. @dagolden's CPAN::Common::Index is a reasonable starting point for an API to resolve module into distribution URLs. I imagine that cpanm would always have to support an index too. But an API makes all sorts of interesting things possible. What are your thoughts about supporting that in cpanm?

[miyagawa]

Yeah, the first time I saw CPAN::Common::Index I thought i could migrate cpanm to use this. The fact is though the module does much less than what cpanm does, particularly because cpanm does what CPAN index can't do - especially version range query with MetaCPAN.

I remember I talked with David and maybe you about adding support for making multiple versions available in one index, or at least on CPAN::Common::Index API level so that you can search for a module with given version requirement.

Anyway i think the direction is right, I would say it might not be as trivial.

[thaljef]

According to the CPAN::Common::Index docs, it does permit multiple versions. But the client is responsible for deciding which version actually satisfies any constraints (via callback). Presumably that could be done using CPAN::Meta::Requirements. So it's not quite what you wanted, but it still makes ranges feasible.

But @dagolden, what do you think about permitting version ranges as the version parameter of a search_packages call? That seems like it would be completely compatible with the current interface. We'd probably have to update CPAN::Common::Index::Mirror how to deal with those. But other backends could allow the server to do all the thinking about version constraints.

Here are some examples of what Stratopan does:
All versions: https://meta.stratopan.com/locate?q=App::cpanminus
One version: https://meta.stratopan.com/locate?q=App::cpanminus==1.7015
Version range: https://meta.stratopan.com/locate?q=App::cpanminus>=1.7012,<1.7015

[dagolden]

It's not supported yet, but my long-stalled plan is to allow it. Taking a version requirement string (based on C::M::R) as a scalar seems quite reasonable, too.

[mohawk2]

For code that uses CMR's version-range capability, this code may be of interest: Perl-Toolchain-Gang/ExtUtils-MakeMaker@710b581

[miyagawa]

This has been implemented using CPAN::Common::Index in the menlo branch, and uses CPAN::Common::Index subclasses to query modules from MetaCPAN and CPAN Meta DB (I added its history API last week).

[miyagawa]

@thaljef feel free to write a CPAN::Common::Index subclass that implements querying against Stratopan, and in Menlo dist I can provide an API so that you can swap the index search backend.

A bit nits though: the query interface looks like a bit odd, especially a raw "2.0" could be interpreted as ">= 2.0" in CPAN Meta spec version ranges. so if you query "?q=Foo2" there's no way to tell if it wants the "Foo2" package or "Foo" with the version requirement "2".

Right now I think you have to normalize the version range and always give ">=2" rather than "2".