[issue7175] Define a standard location and API for configuration files

[Éric Araujo]

Éric Araujo  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Ronald Oussoren]

Change by Ronald Oussoren :


--
nosy:  -ronaldoussoren

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[flying sheep]

flying sheep added the comment:

just because people do something doesn’t mean it’s right.

i guess the tendency for CLI applications to do it wrong comes from

1. their ad-hoc beginnings. you usually start with one script file and extend it
2. availability expanduser('~') is in the stdlib and more well-known than e.g. 
appdirs, and people don’t like to add dependencies to small things
3. the shell and old, widely used applications using ~/.appname, so it’s more 
well-know to do that

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

> I count 17 of those on my Windows machine (!) right now, including .idlerc, 
> .ipython, .matplotlib, .ipylint.d etc.

this is horrible! this is so obviously the wrong thing to do. i hope having the 
module will reduce the number of similar atrocities.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Michael Foord]

Changes by Michael Foord :


--
nosy:  -michael.foord

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[R. David Murray]

R. David Murray added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 02.09.2015 16:37, flying sheep wrote:
> 
> 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 ☺

I think we're mixing two discussions here:

1. How Python itself should install config files, data, etc.

2. 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 03.09.2015 13:37, flying sheep wrote:
> 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.

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...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[flying sheep]

flying sheep added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[flying sheep]

flying sheep added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

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).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Steve Dower]

Changes by Steve Dower :


--
nosy: +steve.dower

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[flying sheep]

flying sheep added the comment:

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 ☺

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On Sep 01, 2015, at 07:15 PM, Glyph Lefkowitz wrote:

>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)

I was really just suggesting reading from other locations for backward
compatibility.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Glyph Lefkowitz]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[flying sheep]

flying sheep added the comment:

no, sorry, but ~/.python is wrong on linux.

there exists a standard about where things belong:

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

it says that configuration stuff belongs into `XDG_CONFIG_HOME`, with a 
fallback to `~/.config/`

i propose to add the `appdirs` module to the stdlib so that programs finally 
don’t have to guess and hack around this kind of things.

https://pypi.python.org/pypi/appdirs

--
nosy: +flying sheep

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

I'm of mixed opinion.  I personally don't like cluttering up my $HOME with a
jillion dotfiles so I appreciate the organization XDG_CONFIG_HOME offers.  But
that also makes things less discoverable.  Looking in XDG_CONFIG_HOME first
with a fallback to $HOME seems like a workable compromise.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Antoine Pitrou]

Antoine Pitrou added the comment:

If this is about existing config files, then we should make sure we don't break 
existing installations. Also, multiple possible locations in the home dir are 
confusing.

If this is about new config files, then ~/.config/python/XXX is probably ok.

I'm not sure what XDG_CONFIG_HOME is but $XDG_CONFIG_HOME doesn't seem defined 
under my shell (Xubuntu 15.04).

--
assignee: eric.araujo -> 
versions: +Python 3.6 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[R. David Murray]

R. David Murray added the comment:

That standard is just wrong, dotfiles belong in $HOME :)  I'm only half joking, 
having grown up with Unix and having had the experience of flailing around for 
a while before I figured out a particular program's rc file was in .config 
instead of where I expected it to be, but I *am* half joking, because putting 
them all in .config is convenient. But most programs don't, so also looking in 
~ makes sense to me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Martin Panter]

Changes by Martin Panter vadmium...@gmail.com:


--
nosy: +vadmium

___
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

[issue7175] Define a standard location and API for configuration files

[Éric Araujo]

Éric Araujo mer...@netwok.org added the comment:

See also #12393.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7175
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Éric Araujo]

Éric Araujo mer...@netwok.org added the comment:

The issue proved more complicated than expected, due to antics of Mac OS X and 
Windows Vista, so I set it aside for later.  I intend to summarize all useful 
comments from the python-dev thread and bug reports comments and try to reach 
agreement for 3.3.

--
assignee:  - eric.araujo
versions: +Python 3.3 -Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7175
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Barry A. Warsaw]

Barry A. Warsaw ba...@python.org added the comment:

I'm mildly uncomfortable advocating many different new dot directories in $HOME 
(e.g. .python2.7 .python3.1 .python3.2).   Let's say -0.  Also, because of 
backward compatibility, I think most configuration files will end up being 
similar enough between Python versions.  Without having thought through all the 
details, it seems that ~/.python would work in general for configuration files 
that are compatible across Pythons, with X.Y subdirectories for version 
specific config files.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7175
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Glyph Lefkowitz]

Glyph Lefkowitz gl...@twistedmatrix.com added the comment:

I would still prefer 
~/.local/something-parallel-to-where-it's-usually-installed for its ease of 
documentation.  But ~/.python/X.Y isn't terribly objectionable.

A minor point about Michael Foord's fallback proposal: I don't know why 
everyone is so keen to stuff things into ~/Library on the mac, but dotfiles 
don't go in ~/Library/Preferences.  While that directory isn't exclusively 
populated with plist files, it's pretty close.  If you want to try for 
consistency with platform convention, 'org.python.distutils.cfg' would be a 
better name for it, but I've never hand-edited a text file in that directory 
either and I get the impression one isn't meant to.

But, since framework builds of Python already has ~/Library/Python/X.Y 
directories that they look in for other things, that location should probably 
be recycled if one wishes to have a fallback.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7175
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Glyph Lefkowitz]

Glyph Lefkowitz gl...@twistedmatrix.com added the comment:

I agree with Michael Foord; my comment on issue 8404 
http://bugs.python.org/issue8084#msg122935 may be of interest to anyone 
looking at this as well.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7175
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Michael Foord]

Michael Foord mich...@voidspace.org.uk added the comment:

It would be nice to settle this.

Personally I would like to see the defaults being:

Linux: ~/.pythonx.y
Mac OS X: ~/.pythonx.y with a fallback of ~/Library/Preferences/.pythonx.y
Windows: ~/pythonx.y perhaps with a backup of AppData/pythonx.y

For both Windows and Mac OS X I would be happy with the fallback / primary to 
be the other way round - it doesn't *really* matter. The API for getting the 
user config direction should always return a list I guess if we have fallbacks.

Someone else in the Python-dev discussion thread (Adal Chiriliuc) expressed a 
preferences for the documents folder on Windows over the home directory. This 
would be fine as well (with AppData still as a fallback). This is used by other 
native windows applications. (In earlier versions of Windows the documents 
folder was explicitly called Documents and Settings.)

We should use pythonx.y rather than just python because (for example) you will 
typically have different packages installed when you have multiple versions of 
Python, and in unittest would then want / need different plugins enabled and 
configured in the unittest config files for each of the versions of Python.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7175
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7175] Define a standard location and API for configuration files

[Éric Araujo]

Éric Araujo mer...@netwok.org added the comment:

I’m retitling the bug, given its broader scope.

Michael Foord added another stdlib example: IDLE config files.

Python-dev thread: 
http://mail.python.org/pipermail/python-dev/2010-August/103011.html

--
assignee: tarek - 
components: +Library (Lib) -Distutils2
title: unify pydistutils.cfg and distutils.cfg and use .local - Define a 
standard location and API for configuration files
versions:  -Python 2.5, Python 2.6, Python 2.7, Python 3.1

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7175
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com