Starting a new thread, since the old one was getting pretty deep and
interwoven with more specific concerns.
Ken Williams wrote:
The "requires recursive build support" I think is true, and we could
easily get stuck there. We should probably just do a one-off (proof
of concept, sort of) specifically for version.pm bundling in M::B
itself, then tackle the larger issue of bundling arbitrary
dependencies.
And I'm game to do this (I'll even offer to accept write access to a
subtree of the Module::Build tree to make this easier on Ken and Randy).
A couple other issues I see in general:
* When someone's already got a certain dependency installed, we
should try to preserve it whenever possible, and not install our
bundled one unless we really need to. This would eliminate the
two-installs-of-version issue above, right? Does it introduce any
other problems?
Bundled packages must always be immediately replaceable by the current
CPAN release (non-bundled package), which may or may not include exactly
the same file(s) that are bundled, or the CPAN release may be a proper
superset. Normally, this would mean that the bundled module's $VERSION
must always be less than the current CPAN release's $VERSION.
At the same time (as Ken points out), if the target machine already has
the CPAN-release of a bundled module installed (and it meets our minimum
$VERSION criteria), then the bundled module must be completely ignored
(not installed, not used for testing, etc).
One solution that comes to mind, specifically with respect to the
version.pm module, is to actually embed a minimal "version" module into
one of M::B's own .pm files (Module::Build::Version springs to mind).
This could be simply appended after the __DATA__ line, and whenever
Module::Build::Version was loaded, it would test for the presence of an
appropriate "version" module and if it wasn't found, it would bring one
into existence via eval of the contents of the <DATA> handle.
This would mean that Module::Build would be functional during testing,
even without a version.pm installed. It would also mean that the user
could install a later version.pm and it would be used instead. It would
even mean that the user could uninstall a CPAN-installed version.pm, and
Module::Build would continue to work.
In terms of maintenance, I'd have to make a very small change to
Module::Build::Version to depend on version::vpp, and then whenever a
new Module::Build release was made, it would be a simple matter to
truncate the __DATA__ and append the latest vpp.pm. The code that
brings this module magically into existence would also need to set the
$VERSION to a value that is always older than the oldest supported
release (or even to 0).
I'm also chagrined to notice now that vpp.pm depends on Scalar::Util for
a certain range of Perl releases; I'm going to try and eliminate that if
possible.
I don't know if this same technique could be used for future bundled
dependencies. But this would be a way to bundle enough of version.pm
for M::B to use, while not precluding the user from upgrading, all at
the expense of a slightly fatter Module::Build::Version file...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
