Config files: dot or not?

Coverage.py reads a configuration file,
which by default is in .coveragerc, with a leading dot. For years I thought
Pylint had no default config
file, because it wouldn’t find .pylintrc, it turns out it looks by
default for pylintrc, no leading dot.

Which is correct?

I guess I was modeling .coveragerc on .bashrc, .vimrc, and all the other
files that clutter home directories everywhere. But is that right? I
asked on twitter
a few months ago:

essential versus incidental, .gitignore or .bashrc are incidental
to any given task, but tox.ini or settings.py are the task
itself.

Hmm, an interesting point. So is .coveragerc essential to coverage.py? It’s
only for overriding defaults, so it isn’t required. But it does specify how
coverage.py should behave.

Should it be coveragerc instead? Or coverage.rc? Opinions? Of course,
.coveragerc files will still be recognized if a new default is used. I
know this is a small point, but I’d like to follow the consensus if
there is one.

Comments

The good think on this solution is that it scales: you can create new global config files (for example, Git supports now also

~/.config/git/attributes

~/.config/git/ignore

) without cluttering ~.

The downside is that’s a very *nix solution; but i think there are equivalent pathes on Non-*nix ones (like Application Data under Windows).

camh 3:34 AM on 26 Apr 2013

No dot. If it is a per-user config file, it goes in .config (overridden by $XDG_CONFIG_HOME) with a filename without a dot.

If it is system-wide, it goes into /etc/[packagename] in a file without a dot.

If it is per-project, it goes into the project directory without a dot.

Also, coveragerc is essential. If you are happy with the defaults, you do not have a coveragerc at all. Otherwise it is essential to overriding the defaults. As a per-project file, it defines how coverage.py runs on that project. It is as essential as a .Makefile

I like the .gitignore/.hgignore precedent. The file is part of how the package is developed, but not part of the package itself. My personal preference is for typing "ls" to show me the package's code, with as little tool-related cruft as possible.

Anonymous 7:51 AM on 26 Apr 2013

I agree with btubbs.

I guess the .gitignore is a similar case. They probably designed .gitignore on .bashrc and they realize the .config opportunity after that. It is kind of common, because .config appeared later.

You can see a few interesting threads about the XDG/.config approach in the Freedesktop site:

Then, about the project root dot presence (current script run path)... I think you should check for both, with and without dot. This allows developers to design the default visibility for the file in the project structure. You are not going to take away the current behavior anyway. Also, for another platforms, you should check their correspondent folders, if you want to support them:

Systems tend to work best if they allow for the broadest possible range of inputs while delivering a narrowly defined range of output themselves. Therefore allowing files with or without dot seems prudent.

There should be a defined location per-system, per-user and per-
project/per-directory. As others have already correctly stated, on *NIX, this is /etc/[name], /home/[user]/.config/[name] (barring xdg-overrides) and /[path]/.[name].rc (dots optional), respectively. On Windows, it is part of the registry or since Windows 7 C:/Users/All Users/AppData/[name]/[config.cfg] (or some such), %USER_PROFILE%/AppData/[name]/[config.cfg] (or some such), and [path]/[name.cfg] (possibly as hidden file if it should not be opened directly).

Add a comment:

Name:

Email:

Ignore this:

Leave this empty:

Web site:

Name is required. Either email or web are required.
Email won't be displayed and I won't spam you.
Your web site won't be indexed by search engines.