Xiong has asked for the wisdom of the Perl Monks concerning the following question:
What overall strategy do you employ when creating a directory structure for development, management, and delivery of a web application?
Over the years, I've employed several different strategies; I've become dissatisfied with each one. As my projects become more advanced and I attempt to formalize my development process, it seems that directory structure becomes more complex and opaque, when the ideal is to be straightforward and transparent.
Here are some of the most important goals I have in mind:
- Orthogonality between my local desktop platform and my remote server. The same relative directory structure should work for both. That is, there should be some local folder projectname/ which corresponds to /home/myaccount/ on server. In the past, I attempted to maintain an exact mirror of www/ on server. I still want this but I also have seen the light and want to store files "below" www/ (those that don't need to be directly accessible via web, such as Perl modules). Still, from the point of view of any given script, the relative structure should be identical. This goes (especially) for test scripts.
- Compatibility with my VCS. I'm using git-gui to manage version control. I need to decide which files to track, which means to settle on a particular folder as version control root. I want to have other folders within the project path, such as backups and scratch folders, which should be excluded from version control.
- Compatibility with module-starter and CPAN. On the offchance that I attempt to upload a project module to CPAN, I intend to use module-starter and try to maintain correct Makefile.PL and .t files, etc., for each module. A difficulty is that module-starter wants to put each module (with its related files) in a directory all by itself. For project development purposes, all the modules should(?) be together, in the hierarchy implied by their names (Project::Base, Project::This, Project::That). For that matter, if ever I do distribute the project, all its modules should go together. Also, the tests should be available to me during development and not buried in deeply nested folders.
- Flat hierarchy. I abhor deeply nested directories. There's merit only up to a point; then nesting gets to be an issue. I especially do not like repetitions of the same word in multiple path parts, such as lib/project/projectname/lib/project/module. When these long paths are displayed or must be typed, they lead to confusion.
- Narrow hierarchy. I don't like to see my project distributed among dozens of folders at the same level. After awhile, it gets to be a chore simply to remember where anything is. I realize that there is a tradeoff: One either has deep nesting, a large number of nodes at each level, or a large number of leaves. I prefer more leaves.
- Maintainability and ability to branch. I like to duplicate the main development code and "stuff" intermediate working versions out of the way, for possible disinterment later. I like to create short what-if scripts; I often mine them for production code. I want all the files I create to be accessible but not in the way. That is, one directory should include only the deliverable project, in its current state.
- Add 2009-11-10: Compatibility with taint mode. I overlooked this in my original post as taken for granted (but to ass-u-me...). Since taint mode removes cwd from @INC, this must be considered when planning directory structure.
All the approaches that I've used have led to some nasty choppery-about. Perhaps when it comes time to upload to server, I have to go hunting for local files and do mulitple cd on server to put everything where it's supposed to go. Perhaps I find myself copying local files mulitple times, or dropping a lot of symlinks around. Often, I spend far too much time just digging around, trying to figure out where I put some file. I feel a more disciplined approach to directory structure would help.
Directory structure (for an individual developer, not part of a team) is a personal decision and I don't expect a one-size-fits-all answer. But I would like to see what others have found that works for them.