Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Arador (8415)

Journal of Arador (8415)

Thursday June 04, 2009
03:43 PM


[ #39075 ]

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. 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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 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


    • > Installing a CPAN module should be as easy as doing
      > apt-get install (package)

      It already is...

              cpan install (package)

      • []

        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

      • Was that sarcasm?

      • 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 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.

  • 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 ev

    • 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?