From: Intransition Date: 2012-03-07T01:55:50+09:00 Subject: Re: Configuration Convention ------=_Part_374_31895807.1331052947361 Content-Type: multipart/alternative; boundary="----=_Part_375_7231795.1331052947361" ------=_Part_375_7231795.1331052947361 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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. ------=_Part_375_7231795.1331052947361 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Monday, March 5, 2012 11:14:24 PM UTC-5, Kendall Gifford wrote:<= blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord= er-left: 1px #ccc solid;padding-left: 1ex;">

After thinking about this li= st, I realize I already put up with loads
of "dotfiles" in my "home" dir= ectory on any Un*x system already, which
system works great since the de= fault 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 abando= ned 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 clu= tter. When viewing files on github for instance, dot files are not hidden.<= /div>


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 withthe fact that some projects commit some of these files into the
project= 's repository (as opposed to individuals simply having their
own persona= l, local copies).

However, I "feel" that a project should consider ad= ding dotfiles to
the project's code repo as the exception to the more ge= neral rule of
having your [D]VCS ignore them by default. I also generall= y feel that
dotfiles should be reserved for the build, test suite, packa= ging, 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<= br>already, IMHO.


Most of those dotfile= really need to be in the repo. I don't think there's much of a choice --ex= pect that the tool maker could use something else besides a dotfile. It wou= ld be unwise not to check in test configuration for instance.
&nb= sp;

> * Guardfile> * Rakefile
> * Gemfile
> * Gemfile.lock
> * Procfi= le

Hmm, I feel a little differently about these "Configfiles". I get = the
lineage, these harkening back to the standard Makefile convention, t= he
capitalization making this file stand apart. Rakefile is the new, rub= y
equivalent of the Makefile. Then came the Gemfile and several otherprojects 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 Guardfi= le 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'l= l also steer away
from using "just any ol' project" that (mis)uses any c= onvention too
much in a manner with which I disagree, without offering e= nough 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. Pe= rhaps it's a philosophical stance against hidden config files, or perhaps v= iewed as helpful to the end-developer to immediately know it (suc= h 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 hi= dden 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 patte= rn instead! And I have to add, my least favorite thing about Configfiles is= that are capitalized, something that has generally been reserve for d= ocumentation files.


> * config.ru

Hmm. Not sure what I would've recommended the st= andard rack
application definition file to be had I been involved, but m= y first
thought is that I'm not a fan of this and I hope that other proj= ects
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 i= t's really just a ruby script. Maybe `rack-config.rb` or just `rack.rb` wou= ld have been a better choice.
 

If your config file is ruby (and isn't a Configfil= e), I'd prefer it
still have the standard "rb" extension. Rake cut out i= ts own extension
of *.rake but I hope no one gets too crazy adding custo= m 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 y= our
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 uncom= mon in ruby projects). It's true that a quick glance can
almost always t= ell me the format, but still....

Aside on this, sure w= ith there where only one possible extension for yaml files. I know the offi= cial 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 mit= igate all
> this. Most likely that would be in the form of a common d= irectory to hold
> all these files, although conceivably, it could be= in the form of a couple
> of shared files --one for Ruby code and on= e 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. Ho= wever, the kinds of
files listed above aren't application-level config f= iles, but
"application-development-level" tools. These kinds of fil= es *should*
stay in the root of the application folder, IMHO, just like = I expect
my system application's to keep my personal configurations in t= he root
of my user directory using dotfiles or dot-directories. App-leve= l
configs can continue to go in a "config" directory.


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

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


I almost never I have personal config fil= es that I wouldn't check-in. I think that must be more of app thing where-a= s I mostly work on libs.

I don't think there is en= ough of a standard personally.


<= /p>

------=_Part_375_7231795.1331052947361-- ------=_Part_374_31895807.1331052947361--