in reply to manage commonly used modules

If the modules are for general use and not only for one project, I would put them in a generally accessible location and keep the project related ones in the project directory.

It would also be useful to give priority to the project lib directories over the general directory so you can use newer or experimental versions of some modules just in a project and have everyone else use the more stable versions.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Replies are listed 'Best First'.
Re^2: manage commonly used modules
by Qiang (Friar) on Feb 26, 2008 at 20:46 UTC
    It would also be useful to give priority to the project lib directories over the general directory so you can use newer or experimental versions of some modules just in a project and have everyone else use the more stable versions.
    i don't think that is possible with mod_perl. it will always use the same module that has already been loaded and multiple version of a module won't work in mod_perl.
      Apache2::Reload can be used to reload a newer version of a module without restarting the server (but you pay in lower performance of the server and your modules get unshared over the parent/children).

      For the multiple-versions-of-the-same-module problem I do not know a solution.

      CountZero

      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James