It's possible this already exists; if it does, I'd appreciate a comment indicating where. I understand this isn't the right place to be making feature requests; I'm just putting this here as a kind of public placeholder to remind me to submit it correctly soon.
Perl feature request: keep track of CPAN modules installed. When installing a newer version of Perl, identify all of those modules, sort them in dependency order, and install them. Ideally, one would need to configure it to do this, but the fact that it could do this would be indicated. Ideally, this would consider soft dependencies in its sort formula, so, for example, Test::Deep would be installed before Perl::Critic, even though Perl::Critic may work without Test::Deep. (However, in the case of a soft dependency loop, soft dependencies would be ignored for the afflicted modules.)
I want this, because nearly every time I've upgraded perl, I've found myself lacking modules I had grown accustomed to having in the old version. I admit, this does give me an opportunity to verify that my soft module dependencies are, in fact, still soft. However, I would probably be more comfortable with frequent perl core updates if these modules were included.
Note that I realize there are times when perl modules are migrated into the stock perl install (for example, Term::ReadLine was, originally, not part of the base install, but it is now), and there are other times when new CORE perl features obsolete a module. In these cases, it would be appropriate to eliminate the modules from the list. In the case of obsolescence, if the new CORE features include a different calling semantics (which will likely be the case), it would be appropriate to issue a warning pointing to the docs that detail the differences.
I can't swear it handles dependencies the way you want, but have you tried the CPAN.pm "autobundle" command?
$ oldperl -MCPAN -e shell
cpan> autobundle
...
Wrote bundle file
/home/david/.cpan/Bundle/Snapshot_2009_08_03_00.pm
cpan> quit
$ newperl -MCPAN -e shell
cpan> install Bundle::Snapshot_2009_03_03_00
... wait a long time...
-- dagolden
Re:CPAN.pm and autobundle?
brian_d_foy on 2009-08-07T04:17:44
Autobundle is inadequate for this. It installs the latest version of a distro, not the one you have installed.
Re:CPAN.pm and autobundle?
tgape on 2009-08-09T19:43:03
Actually, I don't have that concern - I want the latest working version. When I upgrade, I bite the bullet and upgrade.
Of course, CPAN.pm won't give me that; it'll give me the latest version, worky or not. But that's an issue with CPAN.pm, not autobundle.
autobundle will also install everything that was installed before, even if some of them were installed only because they were dependencies of one of the modules specifically requested before, even though that module no longer depends upon them. I don't think one can get around that problem without getting the information to make the bundle from the install process, rather than just checking to see what is installed.
autobundle should be the way to go. Dependencies are resolved in
two ways: because the old installation already had the
dependencies resolved, so you have all required modules also in
the new installation, and because CPAN.pm anyway makes sure that
dependencies are always resolved.
But there's one gotcha: it can happen that left-over modules from
older versions of large distribution may cause the old
distribution to be installed again. Usually one protects himself
by using UNINST=1 while installing distributions, but in reality
almost nobody does it.
Re:autobundle gotcha
tgape on 2009-08-09T19:16:30
Thank you all who answered. Yes, autobundle is an answer to the basic feature request.
For my production stuff, installing extra crap is undesired. But that's not what I'm talking about here.
I'm more focused on my development stuff. Here, I not only want hard dependencies, like CPAN handles, but also soft dependencies.
For example, Test::Critic, as I mentioned, installs just fine without Test::Deep. So, as I understand autobundle's workings (now that I'm looking at it), it will always install Test::Critic first, thus skipping the tests which depend upon Test::Deep. Thus, if there's a problem on my system that those tests will detect, which is system-specific, it'll go undetected.
So autobundle's a crude starting point, but it could use some significant improvements.
recommends in META.yml
srezic on 2009-08-09T22:09:10
So if I understand you correctly, then you want support for the "recommends" field in META.yml? As far as I know CPAN.pm cannot handle "recommends" (yet). But it shouldn't be to hard to implement it.
Re:recommends in META.yml
tgape on 2009-08-12T00:32:35
That is probably accurate, as far as it goes.
:) That having been said, I don't see the recommends as 100% synonymous with the concept. Module A can recommend module B because it is complementary to module A, even though there's no code interactions, and no tests which one can do for the other. I'm not interested in that kind of a relationship, as far as this rebuilding goes.
Specifically, what I'm looking for, for a test-happy build, is the ability to install all test dependencies - both hard and 'recommends' - before running the tests for a new module. If those test dependencies produce a loop, then I'd like the test report for the modules to not be issued until both modules are installed, and then re-run the tests. (Note: if both tests then failed, I'd probably consider this another form of na.)
Disclaimer: I'm being idealistic and stuff here. I've only just installed CPAN::Reporter, and there's a lot about cpantesters I don't yet know. I haven't looked at the code, and I don't know how complicated this would be to code. I don't expect all of this stuff to be implemented any time soon - since actually starting to communicate with and learn more about the rest of the Perl community, I'm really impressed with how much of the stuff I'd like to see coded already *is* coded, or already has some vestigial existence.
