------art_374_31895807.1331052947361
Content-Type: multipart/alternative; 
	boundary---art_375_7231795.1331052947361"

------art_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.



------art_375_7231795.1331052947361
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, March 5, 2012 11:14:24 PM UTC-5, Kendall Gifford wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p>After thinking about this list, I realize I already put up with loads<br>of "dotfiles" in my "home" directory on any Un*x system already, which<br>system works great since the default behavior of the `ls` command is<br>to "hide" dotfiles from me unless I ask to see them.</p></blockquote><div><br></div><div>I think "put up with" is the operative phrase. Yes, `ls` hides them but often file selectors inpps do not and it is very annoying to weed scroll pass them all the time.or 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 aretty convenient place for them anyway.</div><div><br></div><div>So, I doiew 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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p>I recon I'm okay with projects having dotfiles in the project root<br>since it's a well-established convention already. I'm even okay with<br>the fact that some projects commit some of these files into the<br>project's repository (as opposed to individuals simply having their<br>own personal, local copies).</p><p>However, I "feel" that a project should consider adding dotfiles to<br>the project's code repo as the exception to the more general rule of<br>having your [D]VCS ignore them by default. I also generally feel that<br>dotfiles should be reserved for the build, test suite, packaging, and<br>[D]VCS management tools, which is already pretty much the caseor<br>most files. So I think we've already *got* a good convention going<br>already, IMHO.</p></blockquote><div><br></div><div>Most of those dotfileeally 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.</div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p>&gt; * Guardfile<br>&gt; * Rakefile<br>&gt; * Gemfile<br>&gt; * Gemfile.lock<br>&gt; * Procfile</p><p>Hmm, I feel a little differently about these "Configfiles". I get the<br>lineage, these harkening back to the standard Makefile convention, the<br>capitalization making this file stand apart. Rakefile is the new, ruby<br>equivalent of the Makefile. Then came the Gemfile and several other<br>projects have their Awsomefile too.</p><p>I'd like any convention, howeverun]official to steer developers from<br>taking up too much namespace withust Anyoldfile. I'm not sure what<br>gem/project uses Procfile or Guardfile so I can't comment on these<br>(I'm too lazy too Google them right now).ust know that I'll<br>generally be very conservative and won't create aem/lib that has a<br>Configfile unless it really, really makes sense. I'll also steer away<br>from using "just any ol' project" that (mis)uses any convention too<br>much in a manner with which I disagree, without offering enough good,<br>bug-free functionality to make it worth it.</p></blockquote><div><br></div><div>Yea I basically concur. To me a Configfile is basicallyotfile 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&nbsp;immediately&nbsp;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 orhree of them, but imagine if all those dotfiles used the Configfile pattern instead! And I have to add, my least favorite thing about Configfiles ishat are&nbsp;capitalized, something that has generally been reserve for documentation files.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p>&gt; * <a href="http://config.ru" target="_blank">config.ru</a></p><p>Hmm. Not sure what I would've recommended the standard rack<br>application definition file to be had I been involved, but my first<br>thought is that I'm not a fan of this and I hope that other projects<br>don't go too far with this convention of "config.my-extension".</p></blockquote><div><br></div><div>This doesn't bother me as much, but I takeour 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.</div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p>If your config file is ruby (and isn't a Configfile), I'd prefer it<br>still have the standard "rb" extension. Rake cut out its own extension<br>of *.rake but I hope no one gets too crazy adding custom extensions.</p></blockquote><div>Again, would `rake.rb` and `rake-foo.rb`e a better pattern?</div><div><br></div><blockquote class="gmail_quote"tyle="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p>Likewise, if your config format is YAML, please *use* a "yml" or<br>"yaml" extension to make it clear. Just my opinion -- it might be your<br>conventionally named config file, but if it uses another<br>language/markup internally, please use that language/markup's naming<br>convention (this would also apply to JSON, XML, etc, though these are<br>notably uncommon in ruby projects). It's true that a quick glance can<br>almost always tell me the format, but still....</p></blockquote><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p>&gt;<br>&gt; While there are obviously some files that will always remain (e.g. .git),<br>&gt; wonder if it is possible for a convention to ever develop to mitigate all<br>&gt; this. Most likely that would be in the form of a common directory to hold<br>&gt; all these files, although conceivably, it could ben the form of a couple<br>&gt; of shared files --one for Ruby code and one for YAML.<br>&gt;<br>&gt;</p><p>Now, for application-level configuration,ike the convention used<br>by several existing libraries and frameworksf having a "config"<br>directory to hold all your configuration files. However, the kinds of<br>files listed above aren't application-level config files, but<br>"application-development-<wbr>level" tools. These kinds of files *should*<br>stay in the root of the application folder, IMHO, just like I expect<br>my system application's to keep my personal configurations in the root<br>of my user directory using dotfiles or dot-directories. App-level<br>configs can continue to go in a "config" directory.</p></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p></p><p>In summary, I feel that basically/overall, a good, de facto convention<br>is already being followed with me favoring a default attitude of not<br>commiting application-development-level configs, using dotfiles while<br>avoiding Configfiles and config.custom-extension files.</p></blockquote><div><br></div><div>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.</div><div><br></div><div>I don't think there is enough of a standard personally.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left:px #ccc solid;padding-left: 1ex;"><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p></blockquote>
------art_375_7231795.1331052947361--

------art_374_31895807.1331052947361--