Relocating perl itself won't work, but relocating modules should. After all, that's how ppm works. Specifically, it copes the blib/ dir that gets created when the module is built. | [reply]
[d/l]
[select] |
would it still work if you moved say Mechanize.pm to another directory and then tried to use www::mechanize?
the hardest line to type correctly is: stty erase ^H
| [reply] |
If you're now asking about WWW::Mechanize specifically, you can easily answer that yourself.
| [reply] |
Relocating modules ought to work, as long as the files stay in accessible through @INC. That is how PPM, the module installer from ActiveState, works: the prebuilt files, including binaries, are stuffed into a .tar.gz file are de-archived into their final location, by PPM.
Another data point: CPAN modules are tested first in the place where they are built, and install merely copies them over to their final location.
I don't quite understand your question about PERL5LIB... but it definitely won't work if perl runs in taint mode. In that case PERL5LIB is simply ignored. On the other hand: yes, the same format will work regardless of where you move the module to, though I wouldn't be to sure if you move it to another machine...
| [reply]
[d/l]
[select] |
No one mentioned it yet, but if a module has an xs (c compiled) component, just moving the module itself will probably fail, unless the associated blib is moved also, and that can be tricky.
| [reply] |
I advise you to change the destination location by making appropriate cpan configuration changes, then re-install the modules. In this way, you allow the installers (and self-test scripts) to “do what they ordinarily do for you, in the usual way.”
This bypasses many potential problems, while incurring only a modest (one-time) cost in time. Since the code will be installed and self-tested by this process, and because it will install only if all the self-tests pass, it becomes a foundation you can reasonably stand on without worrying (too much) about falling into the river.
(I’m not concerned with how long it takes to build the bridge. The thing that I earnestly want to avoid is the river.)
When I am, for example, “deploying a server or a web site,” I actually build an installation-script, set up a little “sandbox” somewhere, launch the script and sit back to watch it go. I want that script to run clean, start to finish, leaving behind a fully configured module library. If it doesn’t, I fix the script, tear down the entire sandbox (as in: rm -rf sandbox_dir), and try again (and again...) until it works. So now, the deployed server configuration actually has a completely-repeatable installer. There are, of course, tools to assist with that process.
| |