Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re[2]: How do you organize your Perl applications?

by PotPieMan (Hermit)
on Apr 05, 2003 at 02:43 UTC ( [id://248251] : note . print w/replies, xml ) Need Help??

in reply to Re: How do you organize your Perl applications?
in thread How do you organize your Perl applications?

I agree with your directory structure, but I would like to make one further recommendation: Instead of a data directory for configuration files, use the standard UNIX etc directory. This allows you to use data for actual data, such as comma-separated value files that a client sends you.

From the data directory, I generally move to a ddl directory for database definition files and a sql directory for SQL scripts.


Replies are listed 'Best First'.
Re: Re[2]: How do you organize your Perl applications?
by DapperDan (Pilgrim) on Apr 05, 2003 at 12:26 UTC
    Forgive me if this sounds pedantic, but how do you distinguish between DDL and SQL scripts? I only ask because I use a single directory (sql, although I like ddl as well) for this. Aren't they the same thing?

    I also wonder if you have a sibling dml directory which has the definitions for a SQL phrasebook. To be honest, that idea only just occurred to me, but it does seems attractive. Something like:

    +--sql +--dml # database setup scripts and definitions here. +--ddl # data files with phrasebook definitions here.
      My team uses the ddl directory for schema definitions: tables, constraints, triggers, etc. The sql directory is used as storage for what might be called a phrasebook, though we haven't formally come to that concept yet. Definitely something to consider. :-)


Re: Re[2]: How do you organize your Perl applications?
by Anonymous Monk on Apr 05, 2003 at 16:26 UTC
    I disagree with that recommendation.

    There are many cases where you want to allow multiple configurations to co-exist on the same machine. For instance multiple developers on one machine, each with their own home directory. Or staging and production versions of the same site on the same machine, served from different IP addresses.

    Of course if this is for broader distribution and not just for internal use, then be nice to administrators and put configuration files where the sysadmin will expect it - namely /etc. But for internal use...?

      I'm sorry if I wasn't clear before. When I said "standard UNIX etc directory", I meant the following:

      Inside your project directory (whether in your home directory, in CVS, or in some other version control system), create an etc directory for storing configuration files.

      I definitely do not recommend putting everything in /etc. Sorry for the confusion.