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.
  • This is a perfect example of why Perl needs better packaging. Something like PAR [perl.org] seems to be a good idea, but people don't seem to use it. Odd given that many people are having [perl.org] problems [perl.org] with [perl.org] installing dependency-heavy Perl modules.

    The value of CPAN is greatly diminished if we don't have an easy packaging mechanism. Many PHP apps are much easier to install than equivalent Perl ones, solely due to dependencies.

    • If I wanted to release giant spaghetti-code apps that required a large standard library and reimplemented a bunch of functionality over and over again, and had no unit tests and no code reuse between applications at all, I imagine we could do installers as simple as PHP apps too.

      CPAN is complicated for a reason.

      The answer is not to make packages stupider, it's to make the CPAN tools smarter.
      • I don't like PHP and I'm not at all advocating PHP-style code and coding practices (do they have any, apart from 'hack'?). I'm just pointing out that many PHP apps, however dirty, are much easier to install.

        I don't see how bundling prerequisite modules with an application (e.g. Plagger) or large module does any harm. More disk space will be used, but in most cases that won't be a problem. Some may prefer to install modules separately, and I'm not seeking to stop that - I just want an easier way of distrib