Hi all,
One might have noticed that a couple weeks ago I checked in some code
in the M::B repository called inc/latest.pm . The idea is to allow
users to put a bundled copy of M::B in their distribution so that
their users don't have to have it pre-installed, but to still *allow*
users to have their own copy pre-installed if it's at least as new as
the bundled one. For instance, in a Build.PL:
use lib 'inc';
use latest 'Module::Build'; # Loads bundled or existing copy,
whichever's newer
my $build = Module::Build->new(...);
To minimize work for the author, we could add an 'autobundle_mb'
option for M::B.
The nice thing about this is that for reasonably simple build-time-
only prereqs (i.e. no arch-specific pieces, just static .pm files)
(e.g. M::B) the user doesn't need to worry about procuring them.
Thus solving the chicken-egg problem for M::B without higher-level
tools needing to know about configure_requires.
Theoretically we could just bundle a stripped-down version of M::B,
enough to perform installation but none of the fancy author tools
(e.g. creating tarballs, signing distros, etc.). I haven't looked to
see how much this would shave down the yak, but it would be at least
some.
There are some gotchas, though:
1) All of the bundled module's prereqs would need to become prereqs
of the module in question. Inserting the prereqs into the Build.PL
is not so easy.
2) When bundled items depend on each other, it's not
straightforward how to load them relative to each other. E.g. if
M::B started depending on Path::Class or something, how to ensure
that when M::B is loaded we also have access to Path::Class?
Perhaps 1) could be handled by warning the author at 'Build dist'
time that some necessary prereq is missing. The author would have to
add it manually then. Not terribly friendly though.
2) probably just needs more thinking on the implementation in
latest.pm - perhaps just a coderef in @INC would do it, but that's
considered yucky by some.
-Ken
