Thursday 25 April 2013 — This is over 11 years old. Be careful.
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:
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.
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 downside is that’s a very *nix solution; but i think there are equivalent pathes on Non-*nix ones (like Application Data under Windows).
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 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:
http://lists.freedesktop.org/archives/xdg/2008-May/009657.html
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
http://lists.freedesktop.org/archives/xdg/2004-October/003620.html
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.
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.
Based on that... no leading dot I guess?
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: