I like *nix file system organization and always replicate such structure inside every project, so I use the following skeleton:

/home/httpd/<project>/bin        # cmd line scripts
                      cgi-bin
                      etc        # site configs
                      html
                      lib        # local libraries
                      tmp
                      usr        # read only data
                      var        # variable data files
[download]

This structure is well described in Filesystem Hierarchy Standard. There was a really interesting thread on mod_perl mailing list (OTish) Version Control?, where were discussed many related issues (iirc: testing, deploy, local modules, cvs). Look also here: Developer's Directories Tree.

Ciao, Valerio

I'm not sure if you wish to hear what others use for Perl projects or programming projects in general (ie: any language). Since almost all of what I do is done in Perl, I'll assume the former. Also, I don't do very many command-line scripts, as I usually deal with CGI applications. So my CGI approach is what I will post.

This node has been considered with a reason of 'Why is this frontpaged? This is not a perl question'. No, it is not directly related to perl, but perl is definitely a subset of the question asked, so it is a perfectly valid question to be posted, as well as frontpaged. I was rather pleased to see such a question posted, as it offers a break from the usual programming questions. Perl is used for development, so some development questions are going to rise to the sufrace, and it seems prfectly alright by me.

Now on to my general CGI application directory structure. As already noted, this actually changes on a per-project basis. Time to use <pre></pre> tags for the first time (ack!). (Base directory is '/var/www/Port80/ProjectName'):

.htaccess       - Sets project-wide directives

bin/            - Project's command-line tools
    .htaccess   - Deny web access
    readme.txt  - Contains description of all tools

cgi-bin/           - Contains web-accessible perl scripts
        .htaccess  - Enable CGI, desired directives

images/             - Contains all images used
       readme.txt   - Describes subdirectories
       corporate    - Corporate logos, etc.
       display      - Backgrounds, border images, etc.
       incoming     - If I have user-uploaded images

logs/               - Any log files used
     readme.txt     - Explanation of log contents/format

modules/
        .htaccess   - Deny web access
        readme.txt  - Descriptions of contained modules
       

      C:\>shutdown -s
      >> Could not shut down computer:
      >> Microsoft is logged in remotely.
    

The structure I work with is:

..../apache/cgi-bin/tools/app
                          lib
                          log
                          tmpl
                          nodelets
[download]

As the main concept is a web-based platform there are multiple applications under app and the applications corresponding templates under tmpl.

Underneath nodelets are applications that are to be displayed on every web page, such as a Weather.pm or login statistics, or any other arbitrary application.

Our platform design abstracts the presentation/business logic layer from the implementation specific details (such as SQL query's et al), and as such lib will contain domain specific libraries that relate to one or more of the applications under app (for example fetching financial information for business units across the organisation ....lib/Finance/BU.pm). Of course also in lib are the platform libraries that drive the website.

In the case where we have an application that required coupling with a daemon we may include a daemon directory at the same level as app. This has the advantage of being able to leverage of the existing libraries, log structure etc etc without having to maintain to separate copies of the code (in cases where a daemon must use an existing library).

While the daemon option is not really a perfect scenario (i believe an dedicated application server should be used for this), it works quite well and keeps the maintaince down in the absence of a formalised/automated deployment architecture.

ProjectName/
ProjectName/code/
ProjectName/code/bin/ - main script.pl and shell scripts for calling i
+t with params
ProjectName/code/bin/log/ - log files
ProjectName/code/bin/resource/ - config files etc
ProjectName/code/lib/
ProjectName/code/lib/My/Project/Modules/
ProjectName/code/t/
ProjectName/notes/
ProjectName/release/ - make scripts, binaries, and installers
[download]

/J

Hi Jplindstrom


ProjectName/code/bin/log/ - log files
ProjectName/code/bin/resource/


I had the idea that bin contains files to execute. Log files and resources should not be in a seperate directory?. What type of file structure within 'notes' and release?

Besides that where do you keep other programs, such as testing modules, perlmonks answer scripts etc, your own common modules and snippets..

Thanks,
artist

I had the idea that bin contains files to execute. Log files and resources should not be in a seperate directory?.

I see that directory as "the application directory", i.e. it contains the actual program (the .pl file) and the things it needs. It works fine with the way I do things. If you think your program logs should be a level up, I don't see why you shouldn't do that.

What type of file structure within 'notes' and release?

The "notes" dir is free-form. It's too varied between projects to specify in any more detail. The release dir just contains scripts for making a release, and versioned zipped files or installers for each release. The "t" directory contains module tests obviously.


/J

/home/user/projects/PROJECT_NAME/VERSION/
       confs/
            FILENAME.conf
       logs/
            FILENAME.log
       scripts/
            FILENAME.pl
       modules/
           FILENAME.pm
       docs/
       temp/
       trash/


/home/user/projects/PROJECT_NAME/HEAD@ -> link to whatever version
you are working on.
[download]

I keep everything in my home directory under a "proj" sub dir. Each project gets its own directory under there.

One of these days, I'm going to move my home directory to a networked file server to have all my files in one place.

In my little experience using an exported file system causes synchronization problems. Bouncing files via CVS sounds safer. Being a lone ranger and thus without confrontation with co-workers , It's amazing what I learned from this place and threads like that one from mod_perl mailing list.

Ciao, Valerio