Re: Configuration Convention

On Monday, March 5, 2012 11:14:24 PM UTC-5, Kendall Gifford wrote:
>
> After thinking about this list, I realize I already put up with loads
> of "dotfiles" in my "home" directory on any Un*x system already, which
> system works great since the default behavior of the `ls` command is
> to "hide" dotfiles from me unless I ask to see them.
>

I think "put up with" is the operative phrase. Yes, `ls` hides them but 
often file selectors in apps do not and it is very annoying to weed scroll 
pass them all the time. For a long time I promoted the XDG base directory 
standard in hopes that, in time, it would significantly curtail this, 
moving the file to `~/.config/` instead. But I've pretty much given up on 
this. So instead I have abandoned my `~/` directory moved all my files to 
`~/desktop/`, which really is a pretty convenient place for them anyway.

So, I do view reams of dotfiles in toplevel folders as a "great" system. 
It's a clutter. When viewing files on github for instance, dot files are 
not hidden.


I recon I'm okay with projects having dotfiles in the project root
> since it's a well-established convention already. I'm even okay with
> the fact that some projects commit some of these files into the
> project's repository (as opposed to individuals simply having their
> own personal, local copies).
>
> However, I "feel" that a project should consider adding dotfiles to
> the project's code repo as the exception to the more general rule of
> having your [D]VCS ignore them by default. I also generally feel that
> dotfiles should be reserved for the build, test suite, packaging, and
> [D]VCS management tools, which is already pretty much the case for
> most files. So I think we've already *got* a good convention going
> already, IMHO.
>

Most of those dotfile really need to be in the repo. I don't think there's 
much of a choice --expect that the tool maker could use something else 
besides a dotfile. It would be unwise not to check in test configuration 
for instance.
 

> > * Guardfile
> > * Rakefile
> > * Gemfile
> > * Gemfile.lock
> > * Procfile
>
> Hmm, I feel a little differently about these "Configfiles". I get the
> lineage, these harkening back to the standard Makefile convention, the
> capitalization making this file stand apart. Rakefile is the new, ruby
> equivalent of the Makefile. Then came the Gemfile and several other
> projects have their Awsomefile too.
>
> I'd like any convention, however [un]official to steer developers from
> taking up too much namespace with just Anyoldfile. I'm not sure what
> gem/project uses Procfile or Guardfile so I can't comment on these
> (I'm too lazy too Google them right now). I just know that I'll
> generally be very conservative and won't create a gem/lib that has a
> Configfile unless it really, really makes sense. I'll also steer away
> from using "just any ol' project" that (mis)uses any convention too
> much in a manner with which I disagree, without offering enough good,
> bug-free functionality to make it worth it.
>

Yea I basically concur. To me a Configfile is basically a dotfile that the 
tool designer has decided must be seen all the time. Perhaps it's a 
philosophical stance against hidden config files, or perhaps viewed as 
helpful to the end-developer to immediately know it (such as a Rakefile), 
or maybe even a little ego. Nonetheless, it has the same potential of 
clutter --though in part worse b/c at lease dotfiles can be hidden in a 
`ls`. Of course, it's not so bad if there's no more than a two or three of 
them, but imagine if all those dotfiles used the Configfile pattern 
instead! And I have to add, my least favorite thing about Configfiles is 
that are capitalized, something that has generally been reserve for 
documentation files.


> * config.ru
>
> Hmm. Not sure what I would've recommended the standard rack
> application definition file to be had I been involved, but my first
> thought is that I'm not a fan of this and I hope that other projects
> don't go too far with this convention of "config.my-extension".
>

This doesn't bother me as much, but I take your point. It's not ideal to be 
creating a bunch of new extensions when it's really just a ruby script. 
Maybe `rack-config.rb` or just `rack.rb` would have been a better choice.
 

> If your config file is ruby (and isn't a Configfile), I'd prefer it
> still have the standard "rb" extension. Rake cut out its own extension
> of *.rake but I hope no one gets too crazy adding custom extensions.
>
Again, would `rake.rb` and `rake-foo.rb` be a better pattern?

Likewise, if your config format is YAML, please *use* a "yml" or
> "yaml" extension to make it clear. Just my opinion -- it might be your
> conventionally named config file, but if it uses another
> language/markup internally, please use that language/markup's naming
> convention (this would also apply to JSON, XML, etc, though these are
> notably uncommon in ruby projects). It's true that a quick glance can
> almost always tell me the format, but still....
>
Aside on this, sure with there where only one possible extension for yaml 
files. I know the official standard is `.yaml` but everyone seems to use 
`.yml` in practice.

>
> > 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.
> >
> >
>
> Now, for application-level configuration, I like the convention used
> by several existing libraries and frameworks of having a "config"
> directory to hold all your configuration files. However, the kinds of
> files listed above aren't application-level config files, but
> "application-development-level" tools. These kinds of files *should*
> stay in the root of the application folder, IMHO, just like I expect
> my system application's to keep my personal configurations in the root
> of my user directory using dotfiles or dot-directories. App-level
> configs can continue to go in a "config" directory.
>

Yea, I have thought about using `config/` for my tools. But the aesthetics 
always bothered me as it sticks out against the typical three or four 
letter directories. More recently I've actually considered `dot/` as an 
alternative.

In summary, I feel that basically/overall, a good, de facto convention
> is already being followed with me favoring a default attitude of not
> commiting application-development-level configs, using dotfiles while
> avoiding Configfiles and config.custom-extension files.
>

I almost never I have personal config files that I wouldn't check-in. I 
think that must be more of app thing where-as I mostly work on libs.

I don't think there is enough of a standard personally.