in reply to Would you stay with Perl if there were no CPAN?
What makes the CPAN so damned great is that 20 years ago, no-one designed it. People just built stuff to satisfy their needs. 20 years ago it would not have been possible to imagine all the things that now hang off the CPAN, so what we ended up with is something incredibly simple and flexible.
To address your individual points:
- API instead of filesystem: thankyou, but no. A filesystem is simple, and simple is good. API plus filesystem is a nice idea though, and, just like lots of other services hanging off the CPAN, some people thought it would be useful to them, and wrote it. And so we have metacpan.
However, if I'd had to fight with a fancy-pants HTTP (presumably) API instead of a nice simple directory hierarchy, I doubt I'd have produced CPANdeps or cpXXXan. Why? Because I did most of the development offline, and having to fight to set up a web server and someone else's application just so I could develop my application is a barrier to entry that I, being quite lazy, would probably not have bothered to overcome in my free time. And in the case of cpXXXan, I would have had to do a lot more work to replicate or subvert the API so that other people could use the service, instead of just spitting out a plain text index file.
- More centralized: being distributed and mirror-friendly makes it really easy to slice and dice the CPAN, without having to write lots of extra code. It makes it easy to have local copies that you can use offline too.
- Client: Back In The Day, configuring your CPAN client was a useful thing to do. Now, though, it's pretty much automated and so the normal CPAN client is pretty much the same as cpanm, just with useful output.
- Metadata: build vs test vs runtime dependencies actually came very late to the CPAN.
|
---|