I never had the chance to do this but about the name I suppose everything is good as long the path tell you and others something, like: /usr/local/lib/perl5/custom_modules (maybe better path names will come out from other monks who work on lucky OSs)

You can be interested in how-to-change-inc-to-find-perl-modules-in-non-standard-locations and in perlfaq about PERL5LIB

> They are still under somewhat active development..

A separate path for them is mandatory in my opinion: you can have two paths dev and prod never touching the latter until you are sure all your tests (do you have tests, dont you?) passes.

L*

Keeping the development version and the latest production version separate is a good point, and the tests too. Unfortunately there is not a way to do automated testing on most of it. It has gotten complex enough that at least a written checklist is warranted.

According to the exegesis as described in Filesystem Hierarchy Standard the stuff belongs to /usr/local/lib or /opt. You might consider a layout with a "dummy" or "functional" user and the corresponding group with her own home. E.g. like user oracle in group oracle with the home in /opt/oracle.

Best regards, Karl

Thanks, Karl, and everyone.

I've put the production version under /usr/local/lib/perl5/ and placed a corresponding use lib ... in the scripts.

G'day mldvx4,

All of my modules are in one of these directories:

$ perl -E 'say for @INC'
/PB/lib/site_perl/5.36.0/cygwin-thread-multi
/PB/lib/site_perl/5.36.0
/PB/lib/5.36.0/cygwin-thread-multi
/PB/lib/5.36.0
[download]

If you run that command, you should get a similar list. Unless you're running Cygwin, you won't have "cygwin-thread-multi". You may additionally have paths with "vendor". The point being that I have all of my modules in @INC directories; not doing this means repeatedly having to add use lib ... statements to many scripts.

To achieve this, I just run the standard incantation:

perl Makefile.PL
make
make test
make install
[download]

I let Perl add the module code in appropriate places and don't have to think about it any further.

There are a variety of other ways to do this. These seem to be popular, although I don't use them: Module::Build and local::lib.

So, my recommendation would be to pick a method for installing your modules and use it consistently. Let Perl do most of the work for you. :-)

I've no idea how you develop your modules. If you're doing all the work manually, you may want to look at automating some of it (again, letting Perl work for you). You might want to ask about that separately.