...
my %min_version = (Some/Place/Foo.pm => 0.06, # need at least version 
+0.06 of Some::Place::Foo
                   Other/Spot/Bar.pm => 1.35, # need at least version 
+1.35 of Other::Spot::Bar
                   Baz.pm            => 2.72, # need at least version 
+2.72 of Baz
                   );  

my @prereqs;

for(keys(%min_version)) {
  eval {require $_};
  # Ignore modules that don't load.
  unless($@){
    my $m = $_;
    $m =~ s/\//::/g;
    $m =~ s/\.pm$//;
    my $v = $min_version{$_};
    push @prereqs($m, $v);
  }
}

my %h = @prereqs;
....
[download]

...
'PREREQ_PM' => \%h,
...
[download]

Thanks, that's what I first thought too (dynamically generating the dependencies). However, in my case, Log::ger wants to update its *dependants* and I'm afraid adding them to the list of prereqs will trigger a circular dependency. So installing dependants will need to be performed after the installation of itself.

adding them to the list of prereqs will trigger a circular dependency

It's only a problem if those prereqs themselves specify a version of Log::ger that's newer than the Log::ger that's currently installed. (And there must be a Log::ger that's "currently installed", or the "list of prereqs" would be empty.)
So, I guess that's the issue.

IIUC, your question could therefore be generalized as:
"How do I, as maintainer of both the Foo and Bar modules, ensure that Bar, which is dependant upon Foo, is automatically updated whenever Foo is updated ?"
Maybe just bundle Foo and Bar into the same distro ? (I think that would be the "approved" method, though I wouldn't like to assert that it's always desirable.)

Other than that, I can't really think of anything that hasn't already been mentioned.

Cheers,
Rob

How is it possible to depend on the API of a module one doesn't require ?

IMHO if you need another modules API, then you are calling it's subs or methods, hence you need to import them.

Sorry, this really smells like bad design.

edit

anyway, IIRC you are able to list dependencies to other modules and versions as JSON or YAML in a distribution without actually importing them.

update

see CPAN::Meta

I am talking about API in a more general sense instead of the more restricted sense of calling a module's functions/methods or variables. In the Log::ger case, a plugin returns a hash of hooks with names that are agreed upon. This is not enforced "mechanically", which can be a bad design choice in itself but I am choosing minimalism over stricture.

Anyway, making the plugin depends explicitly to Log::ger does not solve my problem. If Log::ger changes in a backward-incompatible way, I *will* break installed plugins unless clients choose to update the plugins (the dependants).

Why not just introduce some code in your distribution that can catch the plugins doing things the old, broken way, and gracefully throw a notice to the user and exit, with the notice advising them to upgrade the broken plugin (caller() could potentially be used to get the plugin name)?

Not ideal, but significantly better than forcing an upgrade of user installed distributions.

Thanks for the clarification, tho that's a bit over my head.

Hope Syphilis approach helps. :)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

There's a "conflicts" key available in META.json:

  ...
  "runtime": {
    "requires": { ... },
    "conflicts": {
      "Log::ger::Some::Plugin": "< 0.5",
      "Log::ger::Other::Plugin": "< 0.3"
    }
  }
[download]

However, as far as I'm aware, CPAN clients don't actually look at this information and use it to upgrade stuff. Your Makefile.PL (or a script in your test suite) could look at it though, and perhaps spit out some very visible warnings.

Ah yes, perhaps CPAN clients should upgrade on conflicts of "Some::Module < 0.123", although this would still cause a circular dependency failure in the case of upgrading dependants.

I'm afraid a warn() in Makefile.PL or diag() in a test script will not be seen by many cpanminus users unless they use the verbose (-v) option. And a die() will be annoying.

Yeah, the lack of feedback to cpanm users is an annoyance.

Just a random thought; not great, but could be helpful. At configure-time, you could modify your pod to add an "INSTALLATION NOTES" section with text like: "This software was installed on $date at $time. At the time of installation, the following packages were already installed but now need upgrading".

toby döt ink