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

use Perl Log In

Log In

[ Create a new account ]

tgape (9307)

  (email not shown publicly)

Journal of tgape (9307)

Monday August 03, 2009
08:37 PM

Perl feature request

[ #39397 ]

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.

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.
  • I can't swear it handles dependencies the way you want, but have you tried the "autobundle" command?

    $ oldperl -MCPAN -e shell

    cpan> autobundle
    Wrote bundle file

    cpan> quit

    $ newperl -MCPAN -e shell

    cpan> install Bundle::Snapshot_2009_03_03_00

    ... wait a long time ...

    -- dagolden []

    • Autobundle is inadequate for this. It installs the latest version of a distro, not the one you have installed.

      • Actually, I don't have that concern - I want the latest working version. When I upgrade, I bite the bullet and upgrade.

        Of course, won't give me that; it'll give me the latest version, worky or not. But that's an issue with, 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 t

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

    • 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

      • So if I understand you correctly, then you want support for the "recommends" field in META.yml? As far as I know cannot handle "recommends" (yet). But it shouldn't be to hard to implement it.

        • 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