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 ]

DAxelrod (4649)

  (email not shown publicly)

I'm interested in hard problems.

Recently, I've started thinking a lot about what CP6AN might look like.

Class::MOP and the Perl 6 Metamodel make me more excited than I'd like to admit.

Also expect occasional wordy technology-related rantings.

Journal of DAxelrod (4649)

Saturday August 05, 2006
10:03 AM

A CPAN Revolution

[ #30537 ]

Incremental, backward-compatible change has its place. But sometimes it's good to be able to break your ties with the past and change how you look at things.

I've become convinced that we need to do this with CPAN.

Don't get me wrong, the CPAN is not only wonderful, it's one of Perl's best strengths. That doesn't mean we can't make it much, much better.

Ok, so what do I mean when I say CPAN? I'm referring to a lot of different things.

  • Module packaging (including metadata and versioning)
  • Installation mechanisms for modules
  • Package managers
  • Package repositories
  • Specification of dependencies
  • Interfaces, both APIs and UIs
  • Probably some other things I've forgotten

It would be a benefit to look not only at our own past, but the accomplishments of other people solving similar problems. There are plenty of packaging systems, library management technologies, etc. and in the great Perl tradition, we should steal as many of their good design ideas as possible.

Step one is to come up with some sort of spec. Step zero is research. What have we designed? What have others designed? What are our needs?

It's going to be an exciting ride.

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.
  • I don’t consider it an unfortunate aspect of its history that CPAN is crufty. All successful large systems start as successful small systems – organic growth is directly correlated with success. In effect, all big systems have some measure of cruft, though some more so than others.

    I am highly skeptical of a push to rebuild CPAN from scratch in an integrated fashion. There are a lot of moving parts involved, and each of them is complex in its own right, so it would take a very long time –

    • I don’t consider it an unfortunate aspect of its history that CPAN is crufty.

      Neither do I. Any large system that hasn't grown organically is going to have deep flaws. All I'm interested in is taking a step back, looking at how we've grown, and maybe considering growth in a slightly different direction.

      I am highly skeptical of a push to rebuild CPAN from scratch in an integrated fashion.

      I would be, too. That's not what I'm suggesting, nor planning to do, nor hoping anyone else will do. Especially no

  • it is 'the' primary, and mostly the only, reason people using perl have remained instead of migrating to ruby or other technologies. Perhaps the only thing that makes perl unique and special is CPAN. People too often forget this and stupidly think that over-engineering it, like p6, will be a revolution in newness and functionality. The road is littered with bodies of the puppy dogs of enthusiasm unleashed every year about this time after the conferences are over and are eager to tackle a 'big problem' only

    • Perhaps the only thing that makes perl unique and special is CPAN.

      I disagree. I think that the CPAN is a part of the larger culture surrounding Perl, and that this culture is the reason Perl is unique and successful. (I also happen to believe that the roots of this community lie partially in the design of the language itself, but that's a different musing.) The people continuing to work in, on, and around Perl are what keep it alive.

      I've kept up with the 6PAN conversations

      Wonderful, I hope I'll be able

  • You can't avoid back-compatibility. You just can't.

    CPAN is so central to the success of Perl 5 that even Perl 6 won't break back-compatibility.

    So let's forget about that right now.

    Large changes are also very tricky.

    There's some small things we can do, in fact we've been experimenting with them in the JSAN implementation.

    Things like:

    - Multiple Indexes

    - Mirror Validation and HTTP-centric rather than FTP-centric transport

    There's also plans from the Win32 side of things like a GUI failure-reporting CPAN client.
    • You can't avoid back-compatibility. You just can't.

      Well, the incompatible syntax of Perl 6 will be doing that anyway. The fact is, there will eventually be code on the CPAN that perl 5 cannot run.* If we do it very carefully, we can use this opportunity to do some really nice things for those Perl 6 modules.

      But apart from things currently being brokenish (which we can blame more on CPANPLUS, Module::Build and Module::Install)

      Wouldn't it be nice to have an infrastructure where we could have all those with