|There's more than one way to do things|
How to lay out private modules?by Tanktalus (Canon)
|on May 11, 2005 at 15:26 UTC ( #456031=perlquestion: print w/replies, xml )||Need Help??|
Tanktalus has asked for the wisdom of the Perl Monks concerning the following question:
A lot of worry goes into proper naming of public modules (e.g., anything on CPAN). And rightly so - these should be descriptive to the point that it's obvious what the module is doing, and it's also further obvious that no one not doing the same thing would use the same name.
However, I have to wonder what others are doing for their private project-specific modules. Our structure has kind of grown up with us - I started the project barely knowing perl at all, so this just didn't occur to me at the time. Since then, I've started to place some modules in subdirectories off the @INC path, but just got to wondering how normal this might be.
Does anyone actually install all their project modules directly to the perl site_lib? Or do you always use lib ...? Do you put your modules at the top of the namespace, or do you have a hierarchy? Are there any rules (whether hard and fast, or merely rules of thumb) that you follow, whether they are written down or not (yet)?
Just as an example, we have all of our extremely-frequently called object types at the root namespace, e.g., 'X', 'Y', and 'Z' (I'm not going to use 'B' as an example ;-}). I'm actually somewhat loath to move them to a sub-namespace, e.g., 'Object::X', 'Object::Y', and 'Object::Z'. However, they all derive from another type, say 'Object::Base'. The string, 'Object::Base' is only used a handful of times (at the top of 'X', 'Y', and 'Z'), so I don't mind having it more clear.
We have a few modules at the root namespace which really should be buried in a subnamespace, but I've just not gotten around to cleaning that up (under the principle of "it ain't broke, yet").
We then use lib ... combined with FindBin and File::Spec to find the project-specific libraries, which are being run nearly directly out of our version control system, so the path is different for each developer. Because we are running it directly from an extracted copy of the version control system, we obviously also cannot install our modules into the global perl environment, otherwise going back a version wouldn't work very well.
I doubt there is such a thing as a "best practice" for this, since we're all in drastically different problem domains, and different practices make sense in different places. I'd just like to expand my horizons a bit here so I can see other ideas, which I sure as heck won't be able to do staying in this job ;-) other than by asking the community at large. I'm hoping there are some others with ideas that would make a lot of sense in my environment which I just hadn't thought of.
Back to Seekers of Perl Wisdom