I think local::lib and the lib::core::only solve this problem. Have you looked into that?
On Mon, Aug 23, 2010 at 11:20 AM, Matisse Enzer <mati...@matisse.net> wrote: > Hi folks, > > I'm revisiting a problem from a couple years back in hopes that a newer, > better solution has or can be created: > > I want to automate the process of building a collection of CPAN modules into > a non-standard directory (so that I can distribute the built collection as > part of another piece software) and I want the installation process to ignore > any already installed, non-core modules. > > For example, my list of modules to install might include > > Params::Validate > > and I want to install using a prefix of /tmp/INSTALL_DIR > > Given that Params::Validate depends upon: > Attribute::Handlers: 0.79 > Scalar::Util: 1.10 > Test::More: 0 > > and that on my build machine: > 'extraslib' => '/System/Library/Perl/Extras/5.10.0' > 'privlib' => '/System/Library/Perl/5.10.0' > and that on my build machine Attribute::Handlers and Test::More are installed > in privlib but Scalar::Util is installed in updateslib > (/Library/Perl/Updates/5.10.0/darwin-thread-multi-2level/Scalar/Util.pm) > > I want my automated build to install in /tmp/INSTALL_DIR not only > Params::Validate but also Scalar::Util because my automated build process > should ignore the Scalar::Util that is instaled in updateslib. > > > In the past I have achieved this by having a complete hierarchy of the > "baseline Perl" modules - the ones to ignore, and by replacing two CPAN > functions at run-time: > > CPAN::Module::inst_version > CPAN::Module::available_file > > I replace them with functions that use the stored hierarchy of the "baseline > Perl" modules instead of the currently running Perl configuration. This > works, but is messy and not very elegant. > > > Does anyone have a better solution? > > -Matisse > >
