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.
  • Just stray thought;

    Would it be sensible to have some kind of "re-testing" infrastructure? E.g. when testing some new module before upgrade, one also checks if there are any other packages that would like re-testing, but with the upgraded version.

    I'm thinking this "re-testing" would at least give authors a faster feedback, presumably reducing the necessity for downgrading in the long run. :)

    • Retesting would likely involve installing tests alongside the code, something we've never done before. It's been discussed, but no action taken.

      Regrettably, when we have a bug crop up in our code, it's often difficult to find it without checking out an old branch and our CPAN dependencies are in a different checkout. I believe that svn externals would alleviate some of this pain, to be honest, but I'd still like to see "authority" become a first class concept on the CPAN (sort of the same way I'd like to

      • My question is why are your dependencies in a different checkout? We've got a directory with all versions of any CPAN dependencies we've ever used, but it's just a flat directory and simply acts as a central place for different projects to copy things from.

        Each project has its own DarkPAN and we point CPAN(PLUS)? at that. When we want to change the version of something, we just "svn rm" the current version in the project's DPAN, "svn cp" the tarball from the central directory, and rebuild the indexes.

        • My question is why are your dependencies in a different checkout?

          This was set up long before I arrived here :/

      • Retesting would likely involve installing tests alongside the code, something we've never done before.

        It does?

        Wouldn't it be enough just to register the wish for retesting when some modules are installed, and then give a proper warning such a module is (about to be) installed? (Later, the warning could be picked up by the build tool and perhaps acted upon.)

  • It seems to me that this information is already available but not yet collected. If tester reports would include the versions of the checked prereqs they could be parsed.

    To think it fully through: It would start with a module that would output prerequisite version information in the test output (if this is possible). A script could parse the reports, extract the version information, and keep track of it in a database.

    Another script could then take this data and generate a snapshot distribution (I'd for exam

    Ordinary morality is for ordinary people. -- Aleister Crowley
  • Bundles let you specify actual distributions. E.g.


    So you can use Bundles to assemble any set of distributions you want, official or otherwise.

    (I'm not sure if it will force a downgrade, but it might. It should act like "install AUTHOR/Foo-Bar-1.23.tar.gz" which would downgrade if the installed is higher)

    -- David

  • From what I understood, this is among the many things that CPAN6 [] was supposed to solve. I looked at the presentation and could not understand it at first, but maybe I will now. As I recall I had read the Aegis version control page with its features-list when I was looking for a VCS and not understanding what most of its features mean, and then after I had used BitKeeper, understanding most of them, so I guess maturity and experience count. :-).

    But like I want to say, the current CPAN ownership, release a

  • My idea for a solution for CPAN to automate distributing the full stack of dependencies of modules. So in addition to a "download" link for a module, there would be a "download with all dependencies" option.

    Some related pieces:

    - Authors should be stricter about which versions of modules they require, and favor the practice of depending on versions they have tested against rather than defaulting to "whatever the newest version of the depending is"... which may not even be released yet!

    - For modules that prov