I know I've been fairly down on Module::Build in the past for not
bootstrapping properly within CPAN dependency traversal.
I've been having some exploratory discussions with a couple of people on
the idea of creating some sort of RDF grammar to provide a generic
metadata publishing mechanism for source repositories of any language.
The idea is to provide ways of linking multiple languages together with
cross-language dependencies better, and so that far more information is
available to auto-packager applications for binary package repositories
such as Debian.
During this discussions I've come to realize that while Module::Build is
certainly our highest profile example of this problem, it's not
necessarily at fault for creating the problem (and thus, is not
necessarily the most appropriate place to fix the problem).
The underlying problem is that we are currently expressing dependencies
incorrectly.
Dependencies vectors in the CPAN dependency graph (and indeed any
platform-independent source repository) are by necessity "complete".
That is, they can only be reliably determined via the execution of
arbitrary code. This has worked wonderfully for CPAN and allowed a great
deal of flexibility.
HOWEVER, of the four stages of module installation (configure, build,
test, install) any dependencies required for the configure stage can NOT
be complete, as it is that stage that determines the dependencies to
start with.
This is where the current Module::Build problem stems from.
1. You have to run configure code to determine dependencies.
2. You have to install dependencies to run the configure code.
Circular dependency. Kaboom.
While requires (runtime dependencies) and build_requires (build, test,
install) META.yml keys are necessarily advisory only with the true
values being determined after running the configure script
(Makefile.PL|Build.PL) we need an additional META.yml key, which I'll
term configure_requires for now.
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.
Which is exactly how Module::Build and most other platform-agnostic
modules work already.
Adding support for this key to the CPAN clients would fix the
Module::Build problem, ExtUtils::MakeMaker issues, and a number of other
problems all at once.
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.
This would also help force end-users to keep Module::Build upgraded, as
the first modules to be released with the new Module::Build would have
that version as a dependency.
Does this sound reasonable?
Ken, what's involved in having it added to the spec?
Adam K
