Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • It might be worth mentioning that when Miyagawa developed cpanminus one of the test cases he used was installing my wiki MojoMojo, the heaviest app on CPAN according to your Heavy 100 index. Thus the actual number is probably higher than 99%, or at least the 1% would be in an obscure corner of the CPAN.
    • It looks like 273 dependencies [] (be patient) (which together guarantee its failure to install). This is nothing close to 99% of CPAN, which contains 8020 authors and 17538 modules []. As Sage Mencken declared [], "For every complex problem there is an answer that is clear, simple, and wrong." Translated into the modern vernacular, "clear" means "99%."
      • Was just replying to Alias's claim:

        With a 99% success rate (using stupidly naive "statistics") every single module on that Top 100 list will fail to install. In a large system with lots of recursive dependencies, it doesn't take much for your install count to grow to 20 or 50 or 100 dependencies.

        Given that logic, and the fact that the top module on that list passes, cpanm would have to work with more than 99% of cpan (or only be broken for very little used modules). I'm quite aware that MojoMojo does depend on most of cpan. I think the 273 dependencies we have is quite sufficient. (and a bit over 1% of the total number of CPAN modules :)

    • I note '(using stupidly naive "statistics")'.

      Clearly, 99% does NOT mean that a 271-dependency distribution must fail according to either "real" statistics, or the real world.

      Plus, there's a bias there that makes the discussion moot, because cpanm has been specifically checked and monitored to work with that distribution.

      • False. No, i didn't add any specific workarounds or anything to MojoMojo and its dependencies. I just used that, along with Jifty, Catalyst and KiokuDB, as a known source of "huge dependencies of well-maintained modules" test bed. I also tested with randomly selected 100 modules from from 02packages, the same thing.

  • that cpanm is well beyond the "99%" level if installing things is a metric. Not that it is -- any connection between "99% solution" and "install succcess rate" was invented entirely by you.

  • At 2200+ SLOC, I don't think it qualifies as a "Tiny" module except in comparison to CPAN(PLUS).

    -- dagolden []

    • ::Tiny was never about specific line count (although that was the main practical constraint).

      If it uses less than 10% of the memory consumption of it's peers, and doesn't have any dependencies, it largely meets the main criteria (even if it achieves this by bundling some modules and using a few other tricks).

  • I remember that before Module::Build could replace MakeMaker, it had to do things MakeMaker didn't do well, if at all (else all it had to do was crib PREFIX support).

    Fortunately not everyone believes that the complexity of a system remains constant (and many people believe that removing 90% of the pain of an existing system is sometimes worth increasing pain 10% in a few other cases).