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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
autobundle gotcha (Score:1)
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, b
Re:autobundle gotcha (Score:1)
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.
Reply to This
Parent
recommends in META.yml (Score:1)
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: (Score:1)
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 ha