Comments on: The power of not being all things to all people

By: Tatsuhiko Miyagawa

Tatsuhiko Miyagawa — Wed, 03 Mar 2010 19:38:19 +0000

brian, i have a minicpan plugin in the git master which works with the local minicpan mirror when the internet connection is offline. It's even configuration-less if you have ~/.minicpanrc (which minicpan web server requires you to set up). I'm talking to rjbs and acme about making it a standard -- All of cpanm plugins can hopefully follow the same pattern: if you need some configuration, you should do that outside and cpanm will pick the sanest default. I'm also excited to work with you on DarkPAN index support -- once I implement the "proper mirror" support I think it's only about configuring which mirror to use for which namespace etc. and it should be straightforward.

By: dagolden

dagolden — Wed, 03 Mar 2010 18:36:31 +0000

Yeah, ironic isn't it? Well, I'm not suggesting putting an XML parser in core, at least.

By: Chris

Chris — Wed, 03 Mar 2010 18:30:05 +0000

So in a post about not being all things to all people, you describe your plans to put an HTTP client into Perl core :) Gotta love the modern age.

--Chris

By: Perl Ain’t Dead…

Perl Ain’t Dead… — Wed, 03 Mar 2010 18:21:30 +0000

[...] Not only are there all these new HTTP based projects there’s a new cpan module installer – cpanminus – which has had some rave reviews. [...]

By: dagolden

dagolden — Wed, 03 Mar 2010 18:00:12 +0000

Good catch. Fixed!

By: PB

PB — Wed, 03 Mar 2010 17:33:58 +0000

You link text says "October 2009" but you actually link to chromatic's February, 2009 archives.

By: brian d foy

brian d foy — Wed, 03 Mar 2010 07:42:33 +0000

Indeed, my second try at cpanminus was to use it with a MiniCPAN, which brings people back to the configuration issue, which isn't the point. :) Now we need a Consumer Reports style chart that shows people which client they should use. I figure most people will be content with cpanminus (espescially when it can auto-discover mirrors, etc), but some people will need some extra features and will have to get the more flexible tools. I've already added many features to App::Cpan that can handle the "zero conf" stuff. The -j switch lets people use any configuration file they like, so I can imagine that we can distribute config files for different sorts of users. The trick is to make the right one the default. Setting "trust CPAN testers" will get rid of a lot of most of CPAN.pm's output. And, you and I have already talked about giving the CPAN.pm internals a thorough scrubbing for its output interface. :)

By: Steffen Mueller

Steffen Mueller — Wed, 03 Mar 2010 07:29:10 +0000

David, It's frustrating to see that you wrote the exact post I would have written (minus the bit about being a CPAN.pm maintainer) if I had managed to get my behind off the ground. So as usual, all that I can do is throw in a resounding "I couldn't agree more to this"! Well, on second thought. No frustration involved :) Thanks for writing up your thoughts on the matter. They're spot-on. Steffen

By: Tatsuhiko Miyagawa

Tatsuhiko Miyagawa — Tue, 02 Mar 2010 23:49:27 +0000

Thanks for the kind words!

Yes, it's so great that every day i learn new things on #toolchain to make the thing work (or learn about some historical corner cases that could have made CPAN/PLUS so complicated, which I take the freedom to ignore :)). And i share your hatred/concern about the fanboy type of people who trashes the older clients without being aware of their historical efforts and that cpanminus owes them for everything, and also owes people running good mirrors (like you) and search.cpan.org sites.

I'm thrilled to continue my work to make cpanm play even betterl with the rest of CPAN ecosystem such as CT 2.0.

xdg++