I would pay close attention to the code in Module::Install that handles this, because you need to be very sure you have it right before it hits an official release.
For example, you can fairly easily get yourself into trouble if you EVER change the API, because code will be written against the bundled version, but may behave differently with the latest version. This is the main reason Module::Install went with the bundle-only, because you can't necesarily trust the APIs to never ever change (granted, we took advantage of that more than we otherwise might have). Personally, I think that the configure_requires is the best fix for this problem. Adam K On 8/15/07, Sendu Bala <[EMAIL PROTECTED]> wrote: > > Ken Williams wrote: > > 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. > > This is something I definitely want to take advantage of. Presumably, > once you've resolved the issues you discuss, latest.pm will be part of > the release on CPAN? > > > 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(...); > > I recall having great difficulty getting a Module::Build subclass to > work correctly (be used) during all possible installation methods if I > had it in a subdir and had to "use lib 'subdir'". In the end I was > forced to just have my subclass in the same dir as Build.PL. Has anyone > reported similar difficulties? Or do you think your above code > suggestion with "use lib 'inc'" would really work with no problems? >
