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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Tuesday October 20, 2009
08:20 AM

Downgrading Moose

[ #39777 ]

One problem with Bundles (and Task::, from what I can see) is that they don't let you specify a particular set of module versions which play well together.

Quite often, I find that I'm trying to downgrade Moose when I need to run an older version of our work code. But that means I also have a few other modules which need to be downgraded at the same time and this becomes painful.

It would be nice to have monolithic "Everything you need for this Moose version" modules, bundling a known-good set of modules together. This would allow a developer to do something like "cpan 'D/DR/DROLSKY/Everything-Moose-0.83.tar.gz'" and get everything they need for that version of Moose installed.

The problem seems to be that CPAN doesn't allow authorities to discriminate between different authorities releasing the same module. I can upload a version of Moose, but it's labeled an "Unauthorized released" if I do. Authorities might help. For example, Class::MOP has the following code:

our $AUTHORITY = 'cpan:STEVAN';

If CPAN had recognized this (it doesn't yet, does it?), I could theoretically bundle Moose 0.83 with Class::MOP 0.88 (and other dependencies) and have this in each module:

our $AUTHORITY = 'cpan:OVID';

And create a distribution which is easy to upgrade/downgrade with full dependencies packaged with it. In fact, we could have several people release identical versions of the same module and the "default" authority would be the owners of that namespace, but you could then do this:

cpan Moose --authority=cpan:SOMECPANID

So if you want an unauthorized release, you must specifically ask for it. Otherwise, the authority is assumed to be cpan:DROLSKY.

Would this work?

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 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.

    AUTHOR/Foo-Bar-1.23.tar.gz

    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 [cpan6.org] 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