Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The difficulty of deploying Perl projects with CPAN dependencies is a real problem. It's not technically a language problem, but a cultural one.

    (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
    • The difficulty of deploying Perl projects with CPAN dependencies is a real problem. It's not technically a language problem, but a cultural one.

      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:

      dh-make-perl --build --cpan Module::Name

      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.