use Perl

• Perl needs better packaging (Score:1)

  by SuperCruncher (3330)

  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.
  • Re: (Score:1)

    by Alias (5735)

    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.
    • Re: (Score:1)

      by SuperCruncher (3330)

      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
• Size does matter (Score:1)

  by sigzero (5768)

  I wonder if all those dependencies are really needed. I was listening to a talk by brian d foy and he made a good point. Perl modules tend to be "all inclusive" of the spec and not "just what you need". That tends to make them rather largish. Now if you are doing something specific that probably works but once you step into framework land, I am not sure if that works as well.
  • Module::Tiny (Score:1)

    by Alias (5735)

    Situations in which only a limited subset of the most basic functionality are required is why the ::Tiny series of modules was created.
    • Re: (Score:1)

      by sigzero (5768)

      Yup, that is what bdf said as well.
• Not really a bug (Score:1)

  by Limbic Region (3985)

  Well, I guess it is a matter of perspective since it is doing exactly what it says it does.
  
  "Currently the cache manager only keeps track of the build directory ($CPAN::Config->{build_dir}). It is a simple FIFO mechanism that deletes complete directories below build_dir as soon as the size of all directories there gets bigger than $CPAN::Config->{build_cache} (in MB)."
  
  Perhaps a better way of handling would be for it to recognize that it is removing directories that it needs for the current installation
  • Re: (Score:1)

    by Alias (5735)

    Even if it does what it says it does, if what is says it does is broken, it's still wrong.
  • Re: (Score:1)

    by dagolden (6584)

    I think that CPAN.pm should only check the cache size after it finishes running the queue, not in the middle. CPAN doesn't guarantee anything about how far over the cache limit the build cache can go and is pretty vague about how often the cache is checked. So I think this is a bug that can be fixed pretty easily.

    It reminds me of the Uncertainty Principle in a way -- you get to exceed the cache limit until you actually go and measure how much cache you're using. As long as that time window is set appro
    • Pretty vague... (Score:1)

      by LaPerla (33)

      There is the config variable scan_cache that determines how often the cache is teared down to its limit. You can set this variable only to two values: "atstart" or "never". This means that (modulo bugs, of course) it is impossible that the cache manager is run in the middle of a session. The usual bug that's happening instead is that somebody (usually Module::Install) calls CPAN.pm recursively. Then "atstart" can be at any point in time.

      I hope that I soon get evidence about what really is going on on Josh
      • Re: (Score:1)

        by jjore (6662)

        Jifty::DBI uses Module::Install which is apparently what kills the Jifty install. It turns out that upgrading CPAN fixes the problem. I suppose that modules with large dependency trees ought to have the non-errant versions of the installer in their pre-req lists.
        
        Perhaps that should be dynamic - if CPAN is asking Jifty about installing it, Jifty can tell CPAN that CPAN needs to be at least 1.90 to be able to successfully install it.
        • Re: (Score:1)

          by dagolden (6584)

          Or maybe Module::Install should just die.
          • Re: (Score:1)

            by Aristotle (5147)

            That’s what I’d say. I understand why people consider it necessary, but I think the effort would have been better invested in fixing Module::Build’s bootstrap problem. (Last I heard, we’re getting there, though, so hopefully Module::Install can indeed just die, soon.)
            • Re: (Score:2)

              by drhyde (1683)

              That still leaves us with the problem of all those people who have bundled Module::Install with their own modules. Perhaps the solution is for CPAN.pm to include its own Module::Install which does nothing but die, and set PERL5LIB to make sure that its Module::Install killer always loads first.

              Bwahahahaha
  • Re: (Score:1)

    by jjore (6662)

    Andreas hinted the new CPAN.pm 1.90 might not have this problem. I'm testing it now.