All of the modules are put under a tree like MyCompany, mainly to keep them as a unit (i.e. in case I ever want to install third-party modules under the same tree). If there are modules that are specific to an application or a specific resource, I put those modules under a subtree of MyCompany. Nothing original here.

I generally install in a directory outside of perl's tree. This allows me to update my code or perl at different times. Also, if I have more than one perl installed (i.e. not just different versions in the same tree), I don't have to install my modules under each perl's tree. There's probably a clever way of configuring perl to do this when you build it, but I haven't looked into this.

To access modules from a script I do something like...

use FindBin qw($RealBin);
use lib ("$RealBin/../lib/perl", "/my/well/known/lib/path");
use MyCompany::MyModule;
[download]

The first 'use lib' path is for testing purposes (e.g. just before an install, or on a test machine). The second is the production path and is a full path so that the script can be moved and still work properly.

This works reasonably well. If you can live with the script not being moved around, I'd suggest not using a full path since it limits changes to the environment. Also, if it weren't too much coding I'd like to be able to turn off the test path during production -- I just haven't thought of a clean/easy way of doing this. I work in a limited environment so that this is not much of a security issue though.