All the Perl that's Practical to Extract and Report
use Perl Log In
Arador (8415)
CPAN2
Recently there has been a discussion about what the New CPAN of Perl6, called CPAN6 by some, is going to be like. I've heard a lot of good ideas from different people, but I'd like to take a slightly different approach. I'm all in for CPAN6, but let's have CPAN2 first.
I don't think it's helpful to reinvent all pieces at the same time. Let's keep the good pieces and get rid of the bad pieces. Module::Build and Module::Install got that right. ExtUtil::MakeMaker sucked ass, so people decide to make something better. We need more of that.
CPANPLUS.pm didn't get it right. It's a better implementation of a wrong idea. CPAN's handling of meta-data sucks. In particular, the way it doesn't deal with dependencies is problematic. We can easily come up with something better. The data exists, let's make it more accessible.
A perfect solution would require a major overhaul, but it could be fixed too by simply adding an extra tier to the CPAN ecosystem that deals with meta-data. I can think of better solutions than that for the future (where the meta-data is integrated into the whole stack), but to be honest I'm more interesting in a solution for NOW than a solution in the far future.
because that's exactly how much difference there is. :-)
--Larry Wall in <10209@jpl-devvax.JPL.NASA.GOV>
Specific (Score:1)
Can you be a little bit more specific about how you want CPAN2 to work?
This has been a sore point for me lately, I really think we need to do a better job of lowering the barrier of entry to access CPAN.
For example, if I do some searches for CPAN (on Google), it's difficult to find clear instructions on how to install stuff. The examples I've seen show something like this:
perl -MCPAN -e shell
BEFORE introducing
Re: (Score:1)
> Installing a CPAN module should be as easy as doing
>
> apt-get install (package)
It already is...
cpan install (package)
Re: (Score:1)
http://rt.cpan.org/Public/Bug/Display.html?id=46045 [cpan.org]
Yes, it has the command-line sugar, but it also needs to be able to complete successfully (I realize this can be problematic with out-of-date installations)
Finally, we need to blat "cpan -i (package)" over the web so people can easily find out how to do it. Maybe even include some pointers to local::lib
Re: (Score:1)
Was that sarcasm?
Re: (Score:1)
Just FYI, cpan doesn't seem to like 'install' from the command line:
cpan install Catalyst::Engine::FastCGI
It looks like you specified 'install' as an argument to cpan(1). This
script is not the CPAN.pm prompt and doesn't understand the same commands.
In fact, doesn't require the extra typing. You probably just want to
list the modules you want to install:
cpan Catalyst::Engine::FastCGI
See the documentation for more details on using this script.
Re: (Score:1)
What you really want is
cpan -i Some::Module.We're already working on this (Score:1)
It may not be entirely obvious, but this is exactly what has been happening over the last few years.
Various bits of the current CPAN model are already being systematically replaced.
META.yml is being replaced with a JSON [cpan.org]-format META.json.
configure_requires (2 years in the making, now in the Perl core, appearing in 5.10.1) has allowed us to upgrade Makefile.PL and Build.PL related modules sanely and do more thorough configure-time testing (and will finally remove the need for some of Module::Install's more ev
Is any of this documented? (Score:1)
I've read many of these discussions (about meta.json, special configuration options, repository options, etc.) and it really is exciting, I just couldn't find much documentation for it, other than journals such as yours and rjbs.
Is there anywhere I could read about this more?