Hi Adam,
On Mar 8, 2007, at 7:36 AM, Adam Kennedy wrote:
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.
Good.
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.
Cross-language dependencies is another topic worth tackling sometime.
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.
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.
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.
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.
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?
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.
-Ken
