Config files: dot or not?

Thursday 25 April 2013 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:

Should config files have initial dots or not? tox.ini vs .gitignore, for example. Reasons?

A few people said they should have dots if they are in your home directory, which is clearly true. But these config files are not meant for the home directory.

Larry Price responded,

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

Hmm, an interesting point. So is .coveragerc essential to It’s only for overriding defaults, so it isn’t required. But it does specify how 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.


I like the move the Git guys did:
is still supported, but the new location is at
The good think on this solution is that it scales: you can create new global config files (for example, Git supports now also
) 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).
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 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.
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:

mac > ~/Library/Application Support
win > x:\Users\foo\AppData\DontKnow\coverage?
win-old > Document and settings?

Also, you can consider a program argument... :P

Whatever choice you take, please, do not add an extra dot before "rc". I dont see a good reason for that, giving the choice already taken for that.
My 2 cents.

If removing it means coverage no longer runs on that project: No leading dot.
If it still runs, but gives less useful/pretty output or something: Leading dot.

I think this coincides with the "essential vs incidental" definition.
Both .coveragerc and coverage.ini seem acceptable to me. Just coveragerc (or coverage.rc) look weird/foreign.
I like how nose just has a [nosetests] section in setup.cfg, so no extra file is needed (if you already have a setup.cfg) just for changing a few defaults.
Piotr Dobrogost 8:50 PM on 26 Apr 2013
I agree with camh - no dot.
Not directly relevant, but: leading dots for hidden files were apparently an unintended consequence of laziness.

Based on that... no leading dot I guess?
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:

Ignore this:
Leave this empty:
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.
Don't put anything here:
Leave this empty:
Comment text is Markdown.