"be consistent" | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
If you are sufferring from conflicts, just install another perl for each project.
As long as the perls don't know about each other, you have a lot of safety. From then on make sure people who do stuff to the perl installation directory just make a note of it, and keep the log under revision control. Third party modules should go into your source control for each project, should be renamed (even trivially). Renaming is crucial, don't underestimate it. If they need complex installation, you should have your own installation tree for each project. To sort out dependencies, you could either 'make dist' for each of your modules, and then put them in your own fake CPAN mirror and have CPAN.pm install their dependencies, or you could install the originals as part of the process. Since your modules would have been renamed, they don't interfere. The recipe script for installing all the dependencies should be under the project's source control. It should know how to fetch perl, build it, get all the modules, install them in the right prefix, and so on and so forth. stvn needed something similar, and that's why Verby was written. It might be useful for making this kind of installation script, but if you are going to script CPAN installations you might aswell use CPANPLUS's backend modules - they are more flexible to program.
-nuffin zz zZ Z Z #!perl In reply to Re: How do you manage module deployment?
by nothingmuch
|
|