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
every Perl script that says:
"Don't be stupid."
--Larry Wall
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
The difficulty of CPAN dependencies (Score:1)
(PAR even seems like it could help a fair bit with this).
Culturally, we tend to say "Oh, and install this slew of modules from CPAN".
If instead we said "just unpack it and visit install.cgi", then we'd have more users of Perl projects.
I like that a number of PHP projects work this way. It's not a technical benefit of PHP that this trend exists, it's a different cult
Re:The difficulty of CPAN dependencies (Score:2)
Perhaps, but in my experience it's a solved problem. The team I work with develops and maintains a large Perl code base on Debian. We deploy our code using packages which in turn specify dependencies on packages for CPAN modules. In the event that we need a module that's not already in Debian or we need a later version, we build our own and put it in our repository. The dh-make-perl utility means that for the vast majority of CPAN modules, downloading a CPAN tarball and building a .deb from it boils down to this one liner:
Of course if we were trying to deploy to 'some random hosting company' then things wouldn't be quite so simple but I don't really see how they'd be any easier if we were using another language. In particular, this has been the major pain point in my recent adventures with Rails.
Reply to This
Parent