From: Intransition Date: 2012-03-06T12:14:47+09:00 Subject: Configuration Convention ------=_Part_1790_10836503.1331003684921 Content-Type: multipart/alternative; boundary="----=_Part_1791_29217197.1331003684921" ------=_Part_1791_29217197.1331003684921 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This is probably one of this topics that will get little attention. Nonetheless... Have other developers started to feel like the *configuration* files for all the various project tools they use are starting to overshadow the rest of the project files? For instance, In many of my projects the meat of the project consists of a few source directories `lib/`, `test` (or `spec`) and sometimes `bin/`, usually four general documentation files `README`, `HISTORY`, `LICENSE` and `MANIFEST` and then of a few non vcs-tracked things like `pkg/`, `log/` and `web/` directories. All the rest consist of various configuration tool files. A quick look at various projects on github provides: * .git * .gitignore * .document * .rdoc_options * .yardopts * .yardoc * .autotest * .travis.yml * .rspec * .ruby * .test * .braids * .vclog * .rvmrc * .rbenv-version * .test-unit.yml * .gemtest * .gemspec -or- foo.gemspec * Guardfile * Rakefile * Gemfile * Gemfile.lock * Procfile * config.ru And there are no doubt many more. Feel free to mention notable ones I've missed. Now, obviously not all of these will apply to every project. But I can imagine that given enough time and a rather thorough developer, a project could acquire configurations for a couple dozen tools. Think code coverage, code analysis, IDE/RAD configuration, etc. I suspect there is a saturation point --at some point it just becomes too much to remember. Even so, it could amount to quite a few files, well exceeding the number of toplevel "meat" files of a project. Another thing to notice is that there are almost universally two file formats: Ruby or YAML, and three naming schemes: dot files, Foofile files and lowercase with special extension files. While there are obviously some files that will always remain (e.g. .git), I wonder if it is possible for a convention to ever develop to mitigate all this. Most likely that would be in the form of a common directory to hold all these files, although conceivably, it could be in the form of a couple of shared files --one for Ruby code and one for YAML. ------=_Part_1791_29217197.1331003684921 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is probably one of this topics that will get little attention. Nonethe= less...

Have other developers started to feel like the *= configuration* files for all the various project tools they use are startin= g to overshadow the rest of the project files? For instance, In many o= f my projects the meat of the project consists of a few source directories = `lib/`, `test` (or `spec`) and sometimes `bin/`, usually four general docum= entation files `README`, `HISTORY`, `LICENSE` and `MANIFEST` and then = of a few non vcs-tracked things like `pkg/`, `log/` and `web/` directories.= All the rest consist of various configuration tool files. A quick look at = various projects on github provides:

* .git
<= div>* .gitignore
* .document
* .rdoc_options
<= div>* .yardopts
* .yardoc
* .autotest
* .trav= is.yml
* .rspec
* .ruby
* .test
* .= braids
* .vclog
* .rvmrc
* .rbenv-version
* .test-unit.yml
* .gemtest
* .gemspec -or- = ;foo.gemspec
* Guardfile
* Rakefile
*= Gemfile
* Gemfile.lock
* Procfile
* config.r= u

And there are no doubt many more. Feel free to m= ention notable ones I've missed.

Now, obviously no= t all of these will apply to every project. But I can imagine that given en= ough time and a rather thorough developer, a project could acquir= e configurations for a couple dozen tools. Think code coverage, code analys= is, IDE/RAD configuration, etc. I suspect there is a saturation point --at = some point it just becomes too much to remember. Even so, it could amount t= o quite a few files, well exceeding the number of toplevel "meat" files of = a project.

Another thing to notice is that there a= re almost universally two file formats: Ruby or YAML, and three n= aming schemes: dot files, Foofile files and lowercase with special extensio= n files. 

While there are obviously some file= s that will always remain (e.g. .git), I wonder if it is possible for a con= vention to ever develop to mitigate all this. Most likely that would be in = the form of a common directory to hold all these files, although conceivabl= y, it could be in the form of a couple of shared files --one for Ruby code = and one for YAML.


------=_Part_1791_29217197.1331003684921-- ------=_Part_1790_10836503.1331003684921--