support specify multiple mirror #29

Merged
merged 1 commit into from May 11, 2012

Projects

None yet

3 participants

@nihen

I use OrePAN repository and it only includes original modules.
I wanna install CPAN modules from other cpan mirror.

SYNOPSYS

PERL_CARTON_MIRROR=/path/to/orepan,http://cpan.metacpan.org/ carton install
@miyagawa miyagawa merged commit 9fbc3b0 into perl-carton:master May 11, 2012
@miyagawa

@nihen I'd like to remove this feature. What's the use case of this, so we can address it in a different way?

@miyagawa

Maybe you should install/mirror all the modules into the OrePAN mirror you created, not just private modules. Also, I could remove the line

        ( $is_default_mirror ? () : "--mirror-only" ),

so that it always falls back to CPAN/BackPAN unless the deployment mode is specified.

Does that work as a workaround?

@miyagawa

I take that back - if --mirror-only isn't set, cpanm's search order is 1) mirror-index (if there is, genrated by carton.lock) 2) metacpan 3) cpanmetadb 4) mirrors

and if you have a DarkPAN, it should be checked before 2/3, and the only way to kill them is to use --mirror-only.

@miyagawa

fixed in 5739372

@pdcawley

That's not really a fix for the following use case. We have a pinto installation with our local modules, and only our local modules. When installing with cpanm, we simply do:

cpanm --mirror http://our-pinto-repo.local/ --mirror http://our-nearby-cpan-mirror ...

The semantics in 5739372 assume that the darkpan 'mirror' is complete, and that's not a good assumption. Falling back to backpan from an incomplete mirror doesn't work either, because backpan only seems to hold the modules that are no longer published in CPAN. Not great.

Parsing PERL_CARTON_MIRROR in the fashion used in this pull request solves our problems and means we don't have to manage our dependencies in both carton and pinto and we're happy.

Please reconsider applying this pull request, or something very like it.

@miyagawa

Falling back to backpan from an incomplete mirror doesn't work either, because backpan only seems to hold the modules that are no longer published in CPAN.

That's not my understanding of how BackPAN works. BackPAN should contain all modules whether it has been deleted or not - however there might be cases where backpan sync isn't up to date. Do you have an idea what kind of distributions fail to exist on BackPAN?

(It might be worthwhile to fall back to MetaCPAN since it also has all the distributions last time I heard)

@pdcawley

Hmm... you're right. Something's weird then.

In the specific case we have (and it seems to be repeatable), our cpanfile specifies

requires 'Geo::IP' => '< 1.42';

And we end up with version 1.39 installed, but DarkPAN seems to have versions 1.40 and 1.41 (as does the mirror we'd be falling back to). Very odd.

Possibly just a specific issue with indexing of one module.

I think we'll just keep our own patched carton in our Pinto so we can fall back to a closer/faster full CPAN mirror than the darkpan mirror.

@miyagawa

Odd indeed, I see them available on backpan:

➜ curl -I http://backpan.perl.org/authors/id/B/BO/BORISZ/Geo-IP-1.41.tar.gz
HTTP/1.1 200 OK
Date: Thu, 17 Oct 2013 22:17:15 GMT
Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8e-fips-rhel5
Last-Modified: Thu, 28 Feb 2013 14:36:19 GMT
ETag: "a9b2ac-1b485-4d6c9d0575ec0"
Accept-Ranges: bytes
Content-Length: 111749
Content-Type: application/octet-stream

➜ curl -I http://www.cpan.org/authors/id/B/BO/BORISZ/Geo-IP-1.41.tar.gz    
HTTP/1.1 200 OK
Date: Thu, 17 Oct 2013 22:17:18 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Thu, 28 Feb 2013 14:36:19 GMT
ETag: "a9b249-1b485-4d6c9d0575ec0"
Accept-Ranges: bytes
Content-Length: 111749
Content-Type: application/x-gzip
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment