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 author in this case is so concerned about not running tests, that he has contorted the dependencies in a circular."

    That post has nothing to do with running tests. I'm merely pointing out that a 'feature' is NOT the same a prereq, yet the toolchain treats them exactly the same way. The 'feature' has it's own tests, and they would be run regardless of whether the second dist is install AFTER the primary dist, or inline with the primary dist.

    The reason I have a circular, is I simply wanted to add a 'featu
    • And yes, I mentioned tests, but only because I'm sick and tired of getting testers reports from broken smokers/toolsets that can't tackle circular deps, dep install orders+@INC, and sending failed reports to ME when one of the prereqs fails to get installed by the smoker. Using the 'feature' part of M::I is a great way to let people know that can install additional dists to get more functionality. Sometimes those extra dists are totall unrelated, soetimes they more like 'expansion packs' that are totall us
      • There's two problems with this though.

        1. A feature IS a set of a dependencies, even if you don't think of it that way.

        2. You shouldn't be using the feature() command to "let people know that can install additional dists to get more functionality.".

        The second one is more important, because you should never assume that the end user themselves understands what your module does (they can be using something several levels up the dependency tree).

        Your feature question is going to do nothing but confuse them.
        • "2. You shouldn't be using the feature() command to "let people know that can install additional dists to get more functionality."."

          Huh? That's EXACTLY what it's for [or how everyone uses it]... "Install X to make Y work"....why everyone does feature 'XYZ Support' in their Makefiles.

          From Task::Catalyst:

          feature 'Log4perl Support',
              -default                  => 1,
              'Params::Validate'        => 0,
              'Catalyst::Log::Log4perl' => '0.1';
          From Catalyst::Log::Log4Perl:

          requires( 'Catalyst'         => '5.60' );
          I'm not trying to do anything different than these lines of code, EXCEPT put that 'feature' line in my main dist [akin to putting the feature line above in the Catalyst dist], instead of a completely separate, third, "Task" dist.

          Why should I have to make a separate Task::Handel just so I don't have a circular when CPANPLUS can get it right, but other tools can't?
          • > Why should I have to make a separate Task::Handel just so I don't have a circular when CPANPLUS can get it right, but other tools can't?

            Reduction of confusion.

            Installation without requiring user intervention.

            Not limiting RedHat users all to the same choices for the answers.

            And finally...

            Just because one particular tool compensates for some particular author mistake, doesn't mean all of them necessarily can or will.