6 ms·
A brief history of CPAN
- dang 12y agoUrl changed from http://blogs.perl.org/users/neilb/2014/08/a-brief-history-of-cpan.html http://blogs.perl.org/users/neilb/2014/08/a-brief-history-of..., which points to this.
- ceronman 12y agoMany thanks to the Perl community for CPAN! Having an easy to access repository of reusable libraries has given us more power to develop cool stuff than any specific language features. That's why nowadays every important programming language has some sort of CPAN clone.
- peterwwillis 12y agoHopefully some day they can expand to support all the functionality added onto CPAN, like PAUSE, cpantesters, BackPAN, CPANTS, Test::*, TAP, CPANPLUS, local::lib, cpancover, cpanratings, cpanminus, Perlbrew, Carton, Pinto, minicpan, Metacpan, CPAN RT, AnnoCPAN, etc. You can go right now and find the test results of building whatever module you want on whatever perl you want on whatever platform you want, find ratings and user comments, and see general quality ratings of a module distribution's construction. The only problem I have with CPAN is its lack of a past. You can't just re-download some module from CPAN you had installed a year ago, because it got removed from CPAN and now it's on BackPAN, so now you have to cobble together some scripts to download all the correct dependencies from BackPAN, and use Perlbrew to get the right perl version + core, and use Pinto to maintain your archive of old modules for the branch/release of your application that it matches. Maybe this is a problem that every language's library repositories have, but it's annoying that there isn't a CPAN standard for "install only the dependencies of module X at the time Module X was released".
- perigrin 12y ago`cpanminus` should install from BackPAN automatically if you ask for an explicitly older version. `cpanfile` and Carton do a fairly decent (IME YMMV) job of locking versions.
- peterwwillis 12y agoIndeed, and Pinto uses cpanminus. Carton, however, does not work well with mod_perl type systems, since you have to 'carton exec' your apps. The whole thing is still a mess, though. For example, some dists never got put into CPAN at all; they were either one-off releases or were shipped in a Linux distro or a perl core at some time or another and then re-versioned for CPAN. So when you try to find the source via cpanminus, you can't, because it literally doesn't exist. So you can either upgrade or downgrade and face whatever incompatibility that means, or use perlbrew and maintain your entire perl stack for every app you ship. Unfortunately it turns out Pinto has a slew of bugs that require you skip all errors (ick). Let's face it, versioning and releases in Perl modules is a goddamn wilderness.
- mhd 12y agoHaving to fight with the node.js package-space just increased my appreciation for CPAN, its content and users. Perl might never had much luster and got slightly outpaced by other scripting languages within the last few years, but it's got a very solid foundation, unlike e.g. Tcl. Managing projects with perlbrew and carton is pretty convenient, and you're free to choose between old-style modular development or various object systems, both lite and heavy, with syntactic sugar or not (recent discovery: Moops).
- davidw 12y agoWhat is 'unsolid' about Tcl? I'll take its source code any day over Perl's.
- mhd 12y agoDon't get me wrong, I'm not trying to Stallmann the language itself, I've always enjoyed working with Tcl. And as you say, it's got a pretty great source code. But you need more than one leg to stand on, and due to its embedded roots and other hysterical reasons, Tcl did a relatively bad job when it came to building a good package library and infrastructure. Which in turn hurt the community, which made for fewer package contributors and so forth. And once Tk lost most of its importance and languages like Lua appeared...
- davidw 12y agoTcl's package/repository story was certainly inferior to Perl's, and many other languages'. That's different from the language not being 'solid' though!
- sigzero 12y agoI love Tcl. It is the quirkiness (meaning non-Algol) of it that appeals to me. The community around it is great. The TCT puts a lot of thought into what goes in as well. I am on the dev list to just keep an eye on what goes on. :)
- 12y ago
- cstross 12y agoA point for non-Perl folks looking at this on HN: While the use of a minor version number might suggest to you that Perl 5.20 is just a bugfix/update from Perl 5.6, that's very much not the case -- in most other language cultures it'd be several major version numbers on and be seen as a vast improvement over the earlier release. The problem for this is that the name "Perl 6" was reserved a long time ago for what has become essentially a different language -- bearing about as close a relationship to Perl 5.x as C++ bears to C. So Perl is stuck with minor version number increments, from 5.6 (which IMO should have been Perl 6) to 5.20 (which equally well might be called Perl 20).
- pre_action 12y ago`perl -v` even goes so far as to say "This is perl 5, version 20, subversion 0". The addition of "v5.20.0" immediately after doesn't sync up very well with that though.
- smacktoward 12y ago> which equally well might be called Perl 20 That was my thought, too -- they should just do what Java did and drop off the "major" version number altogether. In 2014 it confuses more people than it helps.
- cstross 12y agoI believe there is just one obstacle to doing that: Larry. (Perl isn't the product of a corporate culture: it's a labour of love. Unfortunately this can result in some quirky ego-related side effects.)
- kbenson 12y agoI don't think it's fair to lay all the blame for any current blockage on Larry. I think the same issues that apply with just using Perl 7 as the name of the next version apply to just using the secondary version number. It also ignores the validity of the underlying assumption of this line of reasoning, that Perl would be more popular and more used if only the version number was 7.3 or something else that suggested change. I think there's enough holes to be addressed in that argument that making changes based on it is really just flailing in the dark, twiddling bits hoping for a better outcome.
- nanoscopic 12y agoSomething missing from the history is the existence of the "categorical tree" for CPAN modules, the existence of "registered modules", and the recent destruction of both of these features, primarily due to lack of people maintaining CPAN ( Brian D Foy got overloaded ). The interface doesn't show any difference currently between modules that were just thrown up willy nilly and those that went through community discussion and review. It could be useful to mention some of the various binary distribution systems in existence pulling from CPAN ( such as Activestate ) One of the sources for some of the information is very interesting though: http://history.perl.org/PerlTimeline.html http://history.perl.org/PerlTimeline.html
- Animats 12y agoPython needs something like CPAN. Python has Cheese Shop (now called PyPi). It's just a link farm; it doesn't host the modules. Nor does it have any useful curation. So there's no quality control, and no way to fix anything short of forking a new version. That's the big advantage of CPAN. CPAN is the de facto owner of the modules in CPAN, and those modules can be maintained.
- autarch 12y ago> That's the big advantage of CPAN. CPAN is the de facto owner of the modules in CPAN, and those modules can be maintained. This is just false. The CPAN maintainers (really PAUSE maintainers) can transfer ownership of modules away from totally AWOL owners, but it's not like this happens all the time. There's plenty of bitrot on CPAN because the original owner went AWOL and no one else has been motivated enough to ask to take the module over. There is no "CPAN group" who maintains modules.
- mzs 12y agoThe link to 'PAUSE history' requires a login.
- fuzzix 12y agohttp://pause.perl.org/pause/query?ACTION=pause_06history http://pause.perl.org/pause/query?ACTION=pause_06history Pull request on the way.