Repository navigation
Define a standard location and API for configuration files #51424
Description
| BPO | 7175 |
|---|---|
| Nosy | @malemburg, @warsaw, @birkenfeld, @doko42, @pitrou, @tarekziade, @ned-deily, @glyph, @merwok, @bitdancer, @flying-sheep, @vadmium, @zooba |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2009-10-20.11:21:15.035>
labels = ['type-feature', 'library']
title = 'Define a standard location and API for configuration files'
updated_at = <Date 2020-11-03.18:45:18.333>
user = 'https://github.com/tarekziade'bugs.python.org fields:
activity = <Date 2020-11-03.18:45:18.333>
actor = 'eric.araujo'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2009-10-20.11:21:15.035>
creator = 'tarek'
dependencies = []
files = []
hgrepos = []
issue_num = 7175
keywords = []
message_count = 51.0
messages = ['94272', '94279', '94281', '94282', '94284', '94285', '94287', '94288', '94289', '94293', '94412', '94507', '94519', '94523', '94527', '94530', '94531', '94620', '94622', '94623', '94637', '94963', '112366', '112385', '112399', '112407', '112423', '113588', '113646', '113830', '127241', '127320', '127336', '127340', '138940', '249465', '249486', '249487', '249492', '249503', '249508', '249527', '249536', '249550', '249630', '249632', '249633', '249664', '249759', '249768', '380290']
nosy_count = 14.0
nosy_names = ['lemburg', 'barry', 'georg.brandl', 'doko', 'pitrou', 'tarek', 'fwierzbicki', 'ned.deily', 'glyph', 'eric.araujo', 'r.david.murray', 'flying sheep', 'martin.panter', 'steve.dower']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue7175'
versions = ['Python 3.6']
Activity
tarekziade commentedon Oct 20, 2009
[.]pydistutils.cfg will be deprecated in favor of a single
"distutils.cfg", located in .local/ alongside the files added for
example by the per user-site packages.
pitrou commentedon Oct 20, 2009
Why is this? .local/ contains machine-installed files while
.pydistutils.cfg is edited by the user.
tarekziade commentedon Oct 20, 2009
That's what is returned by site.getuserbase()
(which uses PYTHONUSERBASE, and defaults to ~/.local)
PYTHONUSERBASE is the root of Python user-specific paths so it makes
sense to have all Python related files in there.
This came up with the discussion we had with others at Distutils-SIG
read this thread here for more info:
http://mail.python.org/pipermail/distutils-sig/2009-August/012865.html
[.]pypirc should probably go there too.
pitrou commentedon Oct 20, 2009
Well, that makes it the user-specific equivalent of /usr or /usr/local.
Do you put your configuration files in /usr/local ? Why put them
in .local ?
That doesn't make sense actually, since .local isn't Python-specific. :)
pitrou commentedon Oct 20, 2009
I've read the thread now and I think the original proposal of having a
~/.python was more sensible and more user-friendly.
bitdancer commentedon Oct 20, 2009
+1 to what Antoine said.
tarekziade commentedon Oct 20, 2009
The distutils.cfg file is located in the distutils package itself !
So the target is ~/.local/pythonX.X/site-packages/distutils/distutils.cfg
(sorry if that was unclear)
Now, I would totally agree to have a better ~/.NAME to reunite
user-specific *configuration* file for Python, but that would be yet
another directory for user-specific Python files.
pitrou commentedon Oct 20, 2009
Ah, that's horrible. -1 to that.
Configuration files should be easily findable by skimming through the
dot-files in the user's directory. ~/.python fulfills that condition.
tarekziade commentedon Oct 20, 2009
I like ~/.python very much too (that was my initial proposal IIRC).
I guess the best way to add this support is to provide a new api in
site.py, that returns this folder.
Distutils can move pypirc and distutils.cfg file there.
Now for the global distutils.cfg, if we want to have it somewhere else
that the distutils package directory itself, we would need a
"/etc/python" scheme for instance, that could be also added in site.py.
I don't know though how the latter would look under windows
malemburg commentedon Oct 20, 2009
Tarek Ziadé wrote:
+1 on that name as well.
One thing to note though: it is well possible that a user uses
multiple Python versions. With just one such directory, all
versions would look in the same directory for the configuration
files and this could lead to incompatibilities, e.g. Python 2.7
might not like that Python 3.6 needs in some config file (for
whatever reason).
I think Subversion get's this pretty right, so we might want
to follow their scheme:
http://svnbook.red-bean.com/en/1.1/ch07.html#svn-ch-7-sect-1
tarekziade commentedon Oct 24, 2009
The subversion system looks pretty nice !
So here's a modified proposal that covers the python version as well.
= per user configuration files =
~/.pythonMAJOR.MINOR
Examples:
~/.python2.7
~/.python3.1
On Windows, ~ will be replaced by APPDATA if founded in the environment.
== global configuration files ==
On Linux/Mac:
/etc/pythonMAJOR.MINOR
examples:
/etc/python2.7/
/etc/python3.1/
On Windows:
\All users\Application Data\PythonMAJORMINOR
(\All users\Application Data is specified by the Windows Registry)
examples:
\All users\Application Data\Python26
\All users\Application Data\Python31
== standard naming for configuration files ==
The files are all named "NAME.cfg", in all platforms.
== what gets in per-user configuration directory ==
== what gets in global configuration directory ==
== apis added ==
in site.py:
(the names are following site.py naming style)
birkenfeld commentedon Oct 26, 2009
FYI, /etc/pythonX.Y (and /etc/python) are used by Debian; the former
contains site.py and sitecustomize.py, the latter a file called
debain_config.
I can't see how this could become a problem, but maybe someone else does.
34 remaining items
warsaw commentedon Sep 1, 2015
On Sep 01, 2015, at 07:15 PM, Glyph Lefkowitz wrote:
I was really just suggesting reading from other locations for backward
compatibility.
flying-sheep commentedon Sep 2, 2015
of course if there is a chance that some specific config file exists at a known location, it’s the only sane choice to try and look for it there iff it isn’t in its preferred location.
e.g. fontconfig made that switch some time ago: it used to be ~/.fonts.conf, now it’s ${XDG_CONFIG_HOME-$HOME/.config}/fontconfig/fonts.conf
the library will look at the new position and if it can’t find anything there, it looks at the old one.
but for new config files we should follow standards. on windows and OSX there are different ones: see the current discussion on python-ideas for specifics and problems. but on linux the only standard for this which i know is XDG-base-directories, so we should follow that for new config files.
malemburg commentedon Sep 2, 2015
The XDG standard seems to focus on desktop GUI applications and that's also where it's mostly used. Python has it's own installation scheme, which is documented at the top of sysconfig.py and which we've had ever since distutils became part of the stdlib.
For user installs, this bases all installations under the PYTHONUSERBASE dir, which defaults to ~/.local/ on Unix.
So user installs go into ~/.local/pythonX.X/ (I also have a ~/.local/python/X.X/ - not sure where that came from).
Python also uses ~/.pypirc for PyPI, ~/.python-eggs for setuptools, ~/.python_history for readline history.
The installation scheme currently doesn't define a dir for config files, only for "data" files, so adding one would probably be wise.
Since we already own ~/.local/pythonX.X/, why not put config files in there ?
For some extra Unix touch, we could use ~/.local/pythonX.X/etc/ and then move the cache bits to a ./var/ subdir (by defining another new "cache" entry for the schemes).
flying-sheep commentedon Sep 2, 2015
hi mark, i’ve just lengthily replied to you on python-ideas.
in short: nope! many command line tools that are relatively new (among them your examples git and pip) honor the specs, my ~/.cache, ~/.config, and ~/.local/share is full of things belonging to libraries, cli tools, my DE, and of course also GUI applications.
please let’s continue this discussion on python-ideas if you’re still not convinced ☺
malemburg commentedon Sep 3, 2015
On 02.09.2015 16:37, flying sheep wrote:
I think we're mixing two discussions here:
How Python itself should install config files, data, etc.
How applications written using Python should get help
from some module to determine where to install their
config files, data, etc.
For 1. we already have a solution (in sysconfig.py). If you want to
change or amend this, I think a PEP is needed, since the consequences
will affect a lot of users.
For 2. we can use whatever convention or standard is en vogue today.
The module would have to pay close attention to providing backwards
compatibility right from the start, since these conventions are
bound to change over time.
Note that this ticket started with the location of the distutils
config file. The title has since been broadened way too much for
a ticket. I'd suggest closing it as out-of-date and going with
a proper PEP process or development of a new stdlib module
on python-ideas and -dev.
Given the experience with the platform module, I'm not convinced
that the Python release process is suitable to properly respond
to platform changes, so it may be better to simply have a
standard module on PyPI for 2.
flying-sheep commentedon Sep 3, 2015
you’re right about the two problems being mixed, however not about the standards.
also you’re intermingling conventions with actual standards.
the directory standards for all three big OSs are either not going to change or fitted with a backwards-compatibility layer (like windows did with the “My Music/Videos/*” folders):
https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/MacOSXDirectories/MacOSXDirectories.html
http://windows.microsoft.com/de-de/windows-8/what-appdata-folder
https://msdn.microsoft.com/en-us/library/windows/desktop/dd378457%28v=vs.85%29.aspx
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
all three OSs have stable, widely followed standards in place, and the idea of providing a python stdlib API for them received an almost unanimously positive response – with the sole exception being you.
malemburg commentedon Sep 3, 2015
On 03.09.2015 13:37, flying sheep wrote:
I'm not against developing another module based on appdirs for this.
I do question the usefulness of having such a module in the stdlib,
since I've already gone through a similar experience with the platform
module I wrote several years ago. Ongoing development is not really possible
once a module is in the stdlib and older Python releases don't
benefit from new developments either.
Regarding standard vs. convention: that's all smoke and mirrors :-)
A standard that's not being adopted is not a standard. A convention
may well turn into a standard without ever being written down as
one. A module implementing any such standards or conventions will
have to address more than just one way of doing things in order
to stay compatible with existing software or new developments.
That's what I wanted to say.
But this ticket is not about that discussion anyway...
bitdancer commentedon Sep 3, 2015
As someone else mentioned, the freedesktop standard is only really "widely followed" by desktop aps. My own .config directory contains 8 entries, while there are 13 rc files/directories in my homedir (one of which is my X windows manager :)
That's not to mention the 50+ config files in my home directory that don't end with 'rc'....
flying-sheep commentedon Sep 4, 2015
just because people do something doesn’t mean it’s right.
i guess the tendency for CLI applications to do it wrong comes from
on the other hand, GUI applications usually have a build system in place for UI file compilation, need a .desktop file installed, and so on, i.e. need more boilerplate and dependencies from the start, and people have to research how to do things properly. GUI libraries have their built-in standard dirs interfaces as well.
————————
another thing. on the python-ideas thread someone mentioned that
this is horrible! this is so obviously the wrong thing to do. i hope having the module will reduce the number of similar atrocities.
bitdancer commentedon Sep 4, 2015
The "tendency of CLI applications to do it wrong" comes from the fact that they are following the *older* unix (de-facto) standard, which is to put config files in the home directory as dot files. That is, they are *not* doing it wrong, they are following the older unix de-facto standard and not the freedesktop.org standard (which, you will note, is a standard arising out of GUI applications, not CLI applications).
Not, mind, you, that I think .config is a bad standard, I'm just saying that if you want to follow standards you need to account for the legacy standard as well as the new standard.
merwok commentedon Nov 3, 2020
This ticket did not reach a consensus. It seems there would be little value in changing the existing scheme for IDLE and such; external tools can (and often do) already use appdirs; I suggest closing this.
terryjreedy commentedon Feb 27, 2024
The early discussion was about distutils, which is gone. Mark-Andre Lemburg noted that the expanded scope is too broad for an issue ('ticket') and recommended closing. 'merwok' also recommended closing. I agree.
merwok commentedon Feb 27, 2024
Latest discussion: https://discuss.python.org/t/add-cross-platform-user-directories-to-pathlib-standard-library/45390 (also without clear consensus)