This META.yml key, if it exists in a distribution, would inform the
CPAN client that it has dependencies that MUST be installed prior to
the configure script being run at all.
These dependencies would always be static, and could never be changed.
Platform related dependency variability in THESE modules would thus
need to be addressed within that dependency independently, presenting
a single facade.
I think configure_requires is a good step in the right direction. I'm
not completely convinced it solves the entire problem, though. The one
case I'm not sure about is when there are alternative methods of
configuration (e.g. a Build.PL and a Makefile.PL) and they have
different dependencies (e.g. M::B and EU::MM versions).
Also, I agree it would be nice to keep this list static, but that may be
easier said than done. Not sure.
I would suggest that you simply have to list the dependencies for BOTH
of them. At the moment the Makefile.PL produced by Module::Build are
being done in a maximum-compatibility way anyway, so I think it's
probably not going to matter.
Perhaps it's worth noting that it doesn't actually need to be *globally*
static, just *locally* static within the context of a single build. A
mini-language for dependencies could accomplish that - for instance,
something like this:
configure_requires: 'Cwd: 1.2, {PLATFORM=Windows} ? PPM : BuildThing'
For any given build, that evaluates to either
configure_requires: 'Cwd: 1.2, PPM'
or
configure_requires: 'Cwd: 1.2, BuildThing'
without the need for truly dynamic configuration. Locally static
properties that come to mind are things like platform or perl version.
Maybe that's too fancy, though. Not sure.
Probably, minilanguages add a lot of complexity to the CPAN clients,
whereas a fully static dependency keeps things very simple to implement.
You also hit the problem of the minilanguage not being featureful enough
and eventually becoming more complex, and getting loops, and then
becoming turing complete in it's own right, and at that point well we
might as well be using Perl anyway, and we've looped back to where we
started.
More-likely, MOST of the edge cases with static deps can be solved by
abstracting over the problem and pushing the platform-problems or
completeness stuff down into the dependency.
So while you have a static dep on Module::Build 1.23, there's no reason
that Module::Build can't then have a Perl-based
platform-or-anything-else sensitive configure script.
The only case left would be Makefile.PL AND Build.PL in a single script,
and I'd suggest you either 1) Don't list deps for Makefile.PL 2) List
deps for BOTH configure scripts 3) Stop using both (which will happen in
3-5 years)
When Module::Build generated a META.yml it would then automatically
add a configure_requires dependency on the version of Module::Build
used to generate the META.yml in the first place.
Presumably we'd also let users explicitly state the version of M::B
that's required at install-time if they know it, just like we do for
other prereqs. Otherwise, I agree, the current version is a good default.
Absolutely yes. The auto-addition would be a default. I'll note that in
a few small cases Module::Install does this for the install_share
command, and it works just fine.
Also - what happens if a user has an old CPAN, an old M::B, and
downloads a META.yml containing a configure_requires entry? Presumably
that entry would be ignored and the user would miss the dependency
altogether. Any thoughts on how to deal with that gracefully? Maybe
something embedded in the Makefile.PL/Build.PL that enforces it or at
least warns?
There is no graceful way to deal with this. Previously the problem was
small enough to be ignored. When Module::Build came along, it made the
problem larger, but was dealt with partly via also having a Makefile.PL
with the dist.
As far as I can tell, there's simply no backcompatible way to add this.
That said, for most people, the first thing they do is upgrade CPAN.pm.
Or at the very least, CPAN recommends that it get upgraded, which people
will do if the install fails the first time around, which then fixes the
problem.
Anyone that upgrades CPAN would get the new capabilities, and thus be fine.
On the downside, to my mind this probably means that no modules in or
depending on by Bundle::CPAN should be using Module::Install, and should
have an exclusively old-style Makefile.PL.
So that at least the bootstrap problem doesn't prevent you from
upgrading CPAN to solve the bootstrap problem.
And hopefully we'll have support for this working before 5.10.0, if not
certainly 5.10.1 will be ok with it, so from there people will have the
proper.
Once we get this added, the next step is to have the CPAN client itself
be able to tell if it is fatally out of date. And that will solve the
problem once and for all, because we will always be able to forcefully
drag CPAN clients up to the current minimum as it moves.
As for putting something in the Build.PL... yes, I guess, but it would
be big, ugly, and stuck at the top of the Build.PL scripts for several
years.
Ken, what's involved in having it added to the spec?
Just me committing it to the spec pod. I try to be consensusy about it,
though, so of course let's make sure we work through the issues in
public first.
One thing I really like about the idea - it would let us be more
aggressive about adding new M::B features, e.g. extensions to the
dependency syntax that we've been wanting for years.
That's one of the problems it solves, yes.
Adam K
