in reply to Static / Dynamic Linking

Standard practice seems to be to install the modules to a location somewhere in your perl's @INC and then just let the programs which use them find them there rather than designating a specific path, either local or centralized. This is, obviously, a variation on "shared".

Regardless of which layout you go with, source control is very highly recommended. svn and cvs are good, reliable solutions for distributed source control, both of which are well-known, widely-used, and can be installed for free on as many machines as needed. If the lack of source control is due to resistance from other developers, you can even install either of them on your local machine to create your own private repository without disturbing anyone else who may think of it as "more trouble than it's worth".

Replies are listed 'Best First'.
Re^2: Static / Dynamic Linking
by Anonymous Monk on Mar 06, 2008 at 18:38 UTC
    Suppose I use the shared or @INC path... Does source control really help in that case? It may help me with my private development, but when I release, I will have a global effect. (Fixing what ain't broken.)
      Source control becomes vastly more helpful when sharing modules between projects - if you break another project, source control is what will let you quickly and easily roll back the problematic changes (or just show you what all the changes are so that you can figure out why it broke the other project and find a way to make them both work).

      The other tool which becomes much more important for shared modules is a good set of automated test programs. (The Test::* modules from CPAN are the most common way of doing this in the Perl world, but a set of toy test apps can work just as well.) With good tests which cover all documented behaviour of the module, you can be reasonably certain you won't break other projects by verifying that your test results are the same before and after any changes. (Aside from the results of new tests added to verify that the changes themselves work correctly, of course.)