Glyph Lefkowitz added the comment: XDG_CONFIG_HOME is not generally set to anything; the default of ~/.config is usually fine. However, the point is that you _can_ set it to point at a different location. The relevant specification is here:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html The biggest reason I strongly believe we should follow a specification is that Python is not the only software on the system. If I am an ops person that has to deal with Python and Ruby and Java and C software all the time, *any* consistency is a big help. We don't have to follow *this* specification, but we should follow *some* specification (although this specific one looks like a good one to me). The Python community has no special expertise deciding on locations for configuration files, and so we should not be trying to invent a new and better place for them. There are other advantages to following the XDG spec. If we follow it correctly (and not, like Barry suggested, start adding random other directories like ~/.python), users can easily switch between configuration environments by switching the XDG environment variables (both XDG_CONFIG_DIRS and XDG_CONFIG_HOME), which would be a handy way of ignoring both user-specified config files _and_ system-specified ones, to get a pristine virtualenv-like separation between different config files. Given that they are going to need to set these env vars anyway to redirect spec-compliant libraries that their application may be using, it would be nice to just have _one_ set of meta-configuration variables rather than one for Python and one for C and one for Ruby and so on. Consider the fact that distutils respects "CFLAGS", and did not feel the need to invent "DISTUTILS_FLAGS_FOR_THE_C_COMPILER". ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7175> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
