Re: Configuration Convention

On Tue, Mar 6, 2012 at 9:55 AM, Intransition <[e-mail]> wrote:
>
>
> 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 scrol=
l
> 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, mov=
ing
> 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.

Well, if ruby projects start having as many dotfiles in their project
root folders as I have dotfiles/dotdirs in my Ubuntu Desktop install
I'll probably tend to agree w/you more on the dotfile issue and wish
for more of a convention.

>
>
>> 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 agree that the typical project's set of dotfiles do legitimately
belong in the repo, hence my phrase, "...which is already pretty much
the case for most files" above, this referring to the fact that
dotfiles are already pretty much only for "...the build, test suite,
packaging, and [D]VCS management tools" in the typical ruby project.
Which is why I say, yay, "... we've already *got* a good convention
going..." since I'm okay w/dotfiles.

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

Yep, I basically agree (sans the desire to use something besides a
dotfile). I only originally mentioned the whole attitude of "...ignore
them by default" as just that, a default attitude, not so much as a
commentary about existing projects including unnecessary files
(...although there have been some... :-).

But once again, w/dotfiles I don't claim to necessarily have any
technological/organizational reason to hold my opinion. It's just
that, my opinion, subject to change at any moment.

>
>>
>> > * 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 th=
e
> 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=C2=A0immediately=C2=A0know it (such as a =
Rakefile), or
> maybe even a little ego. Nonetheless, it has the same potential of clutte=
r
> --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, b=
ut
> imagine if all those dotfiles used the Configfile pattern instead! And I
> have to add, my least favorite thing about Configfiles is that
> are=C2=A0capitalized, something that has generally been reserve for docum=
entation
> 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.

I certainly just want to be clear that I'm certainly not for proposing
any change in the naming scheme for rake files (lest some other reader
thinks that). But yeah, I have no idea what I would've come up with,
possibly the above or who knows, after some thought the same "*.rake"
system that's in use now. I'm not an absolutist. Oops, I mean, I'm
_usually_ not an absolutist. So I'm open to *some*
tools/gems/libraries creating their own file extension -- it would
just be a case-by-case basis. Again, however, I'm for promotion of a
general attitude of "don't go around creating new, unnecessary file
naming conventions if existing ones fit the bill, _unless it really
makes sense_"

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

Yeah, I noticed the same thing.

>
>> >
>> > 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 aesthetic=
s
> always bothered me as it sticks out against the typical three or four let=
ter
> directories. More recently I've actually considered `dot/` as an
> alternative.

Again, I'd just like to clarify that I specifically *don't* use the
"config" directory for my tools (or "application _developemnt_ level"
as opposed to "application level" config files -- sorry for my lack of
clarity). Meaning, I don't currently and don't propose that your test
suite, build, packaging, etc. files go in the "config" directory. Just
the application level ones.

Now, if you don't like the aesthetics of a "config" dir, you could try
"etc" :-). Just sayin'

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

Yeah, I think you're right, it is generally more of an app thing, and
even there, there aren't many now. Although I've like the practice,
for instance, of *not* checking ".rvmrc" files into an app's repo, for
instance. I've also with *apps* (not libraries) told git to ignore any
".rspec" file too since I'd prefer people use their own ~/.rspec file
and not override my ~/.rspec file with willy-nilly preferences put in
a project-commited .rspec file. If you *must* define a configuration,
you can configure have your setup code use "RSpec.configure". Anyhow,
I'm just pointing out that, at least for app as opposed to lib
development, there are cases and arguments for keeping some dotfiles
out of repos, including ones that I've noticed generally seem to just
be added to a project's repo.

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

--=20
Kendall Gifford
[e-mail]