blakem has asked for the wisdom of the Perl Monks concerning the following question:

I'm working on a fairly trivial module for work that provides an interface to some static content from a third party. The project currently has two parts, a package file with code for accessing and updating the data, and a Berkeley DB file that contains the actual data. (well, more like a lookup table really)

We have our own (small) hierarchy of home grown modules under a $PERL5LIB directory. Therefore, if the package file lives in "$PERL5LIB/My/", Where should the datafile live? "$PERL5LIB/My/Module/mymodule.dbm", "$PERL5LIB/My/Module.dbm", or somewhere else entirely?


  • Comment on Where should a module's static datafile reside?

Replies are listed 'Best First'.
Re: Where should a module's static datafile reside?
by Zaxo (Archbishop) on Aug 24, 2001 at 11:39 UTC

    If your application knows where to find the db, it hardly matters to perl. The issue is interesting, though, because the answer varies according to the type of data and the nature of the system where it's installed.

    It is a good idea to avoid cluttering the PERL5LIB path with files you will not be seeking. The same goes for PATH, MANPATH, LD_LIBRARY_PATH, etc. Don't uselessly overpopulate search paths.

    If the db is read only and may have wider use, one of the /*/share/ hierarchies might be a good choice. If the need may arise to write to the db, /var would be preferred. On a box you don't control, a ~/share or ~/data directory might be the place.

    On Linux, 'man 7 hier' describes the logic behind the filesystem organization. The man page is based on the FHS document. FHS was recently revised as part of the Linux Standard Base.

    Update: Added link to FHS. Swore to quit anthropomorphising perl.

    After Compline,

Re: Where should a module's static datafile reside?
by larryk (Friar) on Aug 24, 2001 at 23:48 UTC
    I use ActiveState perl on Win32 and I find that the "helper" files - such as DLLs - are located at for example perl/site/lib/auto/The/Module.dll so I would suggest that if your module is at perl/lib/My/ you move it to perl/site/lib/My/ (keep perl/lib for std. dist. modules - tidier that way) and put the dbm at perl/site/lib/auto/My/Module.dbm

    just a suggestion

    perl -le "s,,reverse killer,e,y,rifle,lycra,,print"
Re: Where should a module's static datafile reside?
by AidanLee (Chaplain) on Aug 25, 2001 at 03:35 UTC

    If your data has no use outside the module it's tied to, place it somewhere nearby under $PERL5LIB. If the data has a life beyond interacting with your module (or if your module has a life beyond acting on this one data file), I would recommend keeping it out of your library hierarchy all together, and feeding it's location to your module (rather than hard coding it).

    For my own projects I tend to do this:

            lib/   <-- project specific modules
            bin/   <-- project scripts
            data/  <-- project datafiles
Re: Where should a module's static datafile reside?
by Anonymous Monk on Aug 26, 2001 at 19:22 UTC
    In your specific case, I would place the datafile with the application the data is provided by. I tend to like things grouped together that were delivered together. I would then have a config file for the script that points to the database file. This makes it easier to figure out what came with what. For some reason, I can never rely on someone reading the docs I write. Fancy that ;-). If you are working on a system where someone else has the chance to arbitrarily move the application, then I would suggest a global .ini file or shell vars to specify the applications location. This allows all applications to utilize the same info without having to know where to look for anything but the .ini/shell vars (and it is now not your resposibility). Now, the sysadmin can move the app around to their hearts content (been there!) and your app always knows right where to look - and if it does not, it is not your software that is broken, but their configuration. CYA big time. I hate those 2:00 am phone calls because someone did not do what they were supposed to do. Now, they get the phone calls, because the app says "configuration elements missing, call systems administrator." Wahoo!

    I have a few rules of thumb as to where the datafile belongs.

    I - If the datafile is used only by the module, and never by the USEing program(s), then I tend to put it in a data directory in the Module directory (never in the same directory - I think I am superstitious ;-) I find I almost never have a datafile that fits this!

    II - If the datafile is used by the program, then I place the datafile in a subdirectory called data in the program directory.

    III - If the datafile is to be used by multiple programs (not simultaneously) in the same application, then I place it in a data directory in the main application directory.

    IV - If the datafile is to be used by multiple applications, then I use either a system directory (/usr/local/data, /home/data,/usr/data ...) or a web directory (depending on how the applications are used).

    Typically I find that almost all datafiles I use do not belong with the Module, as the dat they contain is related to the application itself.

Re: Where should a module's static datafile reside?
by runrig (Abbot) on Aug 26, 2001 at 05:58 UTC
    Its all a matter of opinion, of course, but mine is to put the file in the same directory or a sub directory as the module (maybe a subdirectory so the search path is not as cluttered as Zaxo suggests). Then its easy to find the file by parsing the path out of the __FILE__ variable.

    I think there's plenty of examples of config and data files under the @INC directories, another won't hurt.

Re: Where should a module's static datafile reside?
by petdance (Parson) on Aug 27, 2001 at 03:18 UTC
    Also remember you have the <DATA> file handle at the end of the module, if your data is small enough. That way, everything's self-contained. I like to roll my own little mini-format of data, keep it at the end of the module, and read it in the INIT block.

    But then again, if you're keeping .db files, chances are you've outgrown that.

    <megaphone> Throw down the gun and tiara and come out of the float! </megaphone>