Convention Over Configuration: A Way Forward?

[Trans]

On Sun, Jan 8, 2012 at 12:20 PM, Kevin Krammer <kevin.krammer at gmx.at> wrote:
> You seem to have replied only to me, not to the list.
>
> On Sunday, 2012-01-08, you wrote:
>> On Fri, Jan 6, 2012 at 8:53 AM, Kevin Krammer <kevin.krammer at gmx.at> wrote:
>> > How would that improve upon any of the holdback reasons you cited above?
>> >
>> > Is there any public statement of developers in the groups "indifferent"
>> > or "uncertain" that they would support a fixed location but cannot be
>> > bothered to read a single environment variable?
>>
>> Yea, the simple fact that they don't do it.
>
> I am afraid I don't get that. What does "it" refer to?
> Making a public statement? I am not sure not making a public statement in
> favor of something can be counted as an implicit public statement in favor of
> something.

I mean that they don't use the environment variables.

>> It might seem trivial, but
>> to programmers every additional adjunct is another maintenance issue.
>> With XDG base directory standard it means eiterh rolling my own code
>> or having dependency on an external library.
>
> Hmm. I haven't done any application with just low level APIs but reading an
> environment variable and a string comparison seems indeed rather trivial to
> me. Though I can only speak for languages I've used so far, e.g.C/C++, Java,
> Python. Might be more complicated elsewhere.

Yea, it's not that complicated to implement. That's true. But it is a
bit more to take into consideration. And sometimes even a bit more can
seem like a lot when it is unfamiliar. Part of it is probably a
perceptual issue, i.e. Am I using XDG base directory standard
correctly?

Aside, I also think `/etc/xdg/` default is a bit of a turn off for
system wide configuration. Why isn't it just `etc/` ?

>> By using a fixed path,
>> the code need not have to worry about any of that. Thus making it much
>> easier to implement and support.
>
> Ok, based on the assumption that reading an environment variable could be
> difficult the question is why don't these application developer just hardcode
> $HOME/.config?
>
> That would always keep $HOME clean of "hidden" config files and additional go
> along XDG using applications in a majority of setup without any drawback.
>
>> > How would the proposed inconfigurability make the location more widely
>> > known?
>>
>> By gaining acceptance into FHS proper. FHS would have no problem
>> accepting fixed locations. Indeed, at this time the standard
>> explicitly designates the use of home dot files.
>
> Interesting thought.
>
>> And I disagree with the term "inconfigurability". It's would still be
>> configurable, but via the file system itself, not the environment
>> variables.
>
> True, though I find symlinks to be more tedious to switch and temporarily
> override.

That's a good point.

> Anyway, I guess my main puzzlement is still whether developers currently not
> hardcoding $HOME/.config are not doing it because there could be systems where
> XDG_CONFIG_HOME points to something else.
>
> Cheers,
> Kevin