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.
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
cpan -i
I mean really, put the newbie into a strange environment? Not a great idea IMHO.
http://sial.org/howto/perl/life-with-cpan/ is really terrific, I mean, a wonderful resource. However, there's no clear synopsis on the top on how to install, say, Moose.
Installing a CPAN module should be as easy as doing
apt-get install (package)
Perl IS CPAN, and we need to make it more accessible to the newish developer.
Re:Specific
Alias on 2009-06-05T02:50:00
> Installing a CPAN module should be as easy as doing
>
> apt-get install (package)It already is...
cpan install (package)
Re:Specific
grink on 2009-06-05T03:06:49
http://rt.cpan.org/Public/Bug/Display.html?id=46045
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:Specific
Aristotle on 2009-06-07T02:43:32
Was that sarcasm?
Re:Specific
grink on 2009-06-08T18:09:01
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:Specific
Aristotle on 2009-06-08T20:02:14
What you really want is
cpan -i Some::Module.
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-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 evil ways of doing things).
The upcoming "MYMETA.json" file removes the problem of Makefile.PL/Build.PL communicating dependencies to CPAN.pm and any other processing that build packages (experimental support now in Module::Install, but coming to everything else eventually)
The 07mirror.json file and Mirror::JSON will fix the problem of finding a CPAN mirror by providing a fully automated mechanism for mirror discovery and selection, with detection of stale mirrors and the ability to tolerate currently being on a mirror that goes stale.
And CPANDB gives us a glimpse of what a new next-generation SQLite index would look like, that you can download and use immediately (without having to parse and process three separate index files).
It's not that we aren't doing anything.
It's just that after the Module::Build debacle, we've learned not to noisily promote new CPAN improvements until they are fully completed and safe for universal use.
Is any of this documented?
xsawyerx on 2009-06-08T10:06:27
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?
