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.
  • Just in case I'm misinterpreting that output, it looks to me very much like Test::Class has a dependency which has upgraded to a broken version.

    This reminds me of two things I'd really like for CPAN to have:

    1. Ability to blacklist specific module versions, both in requirements (my module requires File::Next >= 1.0 and not 1.04, for example) and overall (effectively, we pull this version from the repository.)

    2. An option to install the test scripts for each module some place, and a script to re-run those test scripts when considering installing a module in the dependency graph for the associated module.  That is, if I have App::Ack installed, along with its tests, and I attempt to install File::Next 1.04, while it passes its own tests, it fails App::Ack's tests, and so it's not blindly installed, and therefore my system isn't broken.

    I do realize that the latter feature would require a lot of work and additional features - for example, when processing an install queue, build a single blib directory for all of the modules in the queue, so that the tests can run in the context of all of the upgraded software, instead of just what we have processed thus far.  (That would also be useful for handling circular dependencies - that problem goes away, so long as they aren't build-depends.)  But there's a lot of things that take a lot of work but are really needed.

    • > 1. Ability to blacklist specific module versions, both in requirements
      > (my module requires File::Next >= 1.0 and not 1.04, for example) and
      > overall (effectively, we pull this version from the repository.)

      This one is certainly possible for non-configure_requires dependency, because we already have a turing-complete configuration phase. In pseudo code...

      if ( installed File::Next is 1.04 ) {
              requires File::Next 1.05
      } else {
              requires File::