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?
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.
Re:Re-testing?
Ovid on 2009-10-20T15:43:52
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 see packages and classes separated, but that's not going to happen in Perl 5).
Re:Re-testing?
elliot on 2009-10-20T16:38:37
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.
Re:Re-testing?
Ovid on 2009-10-22T05:49:11
My question is why are your dependencies in a different checkout?
This was set up long before I arrived here
:/ Re:Re-testing?
sjn on 2009-10-20T16:47:10
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 example be thinking of M:I's bundle feature that bundles other dists with yours AFAIU) with the highest possible dep versions. Bonus points if old snapshots are remembered and new ones only generated if all dep versions in the new snapshot are at least as high as in the new ones.
A side-effect of this would be that you'd have, for example, Catalyst community snapshots that come with all batteries included.
I'm not sure if there'd be something blocking this. It was more of just a quick thought.
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 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 and versioning system leaves a lot to be desired. It seems like a lot of patchwork to me with hacks upon hacks. I still don't understand why there can only be one namespace master in PAUSE, and not several who can hand out uploading bits. And naturally there should be a way in the admin screen to assign ownership to all modules maintained by the Catalyst team to any of the Catalyst maintainers. And naturally, people would sometimes love to create alternative CPAN branches of modules that were forgotten or unmaintained without their missing-in-action author's approval, or as a github-like fork of the module that will hopefully be merged into the main one.
CPAN is probably better than most of the source code repositories for other languages that I know about. Even its comprehensiveness is second to none. But in its years it has accumulated a lot of historical cruft, partly due to "Release Early, Release Often". So I think something like CPAN6 will be a good thing, assuming we can get everyone to gradually switch to it without breaking production (possibly by syndicating stuff to the old CPAN and its mirrors.).
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 provide Pure Perl and XS alternatives, there should be a standard way for automated tools to build the Pure Perl version.
- Like Ubuntu or Debian, we could make use of a "build farm" that would compile the XS bits on various platforms.
In your case, it would mean that when selected an old version of Moose, you would have the option to download the old version with all dependencies that the old version depended on, instead of getting the old version...and then getting all the newest dependencies.
It's my dream.
