[Python-Dev] proto-pep: plugin proposal (for unittest)

[Ronald Oussoren]

On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:

> 
> On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
> 
>> 
>> On 1 Aug, 2010, at 17:22, Éric Araujo wrote:
>> 
>>>> Speaking of which... Your documentation says it's named ~/unittest.cfg,
>>>> could you make this a file in the user base (that is, the prefix where
>>>> 'setup.py install --user' will install files)?
>>> 
>>> Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
>>> other in the user home directory (or %APPDATA% on win32 and
>>> what-have-you on Mac) is unnecessary clutter. However, $PYTHONUSERBASE
>>> is not the right directory for configuration files, as pointed in
>>> http://bugs.python.org/issue7175
>>> 
>>> It would be nice to agree on a ~/.python (resp. %APPADATA%/Python) or
>>> $XDG_CONFIG_HOME/python directory and put config files there.
>> 
>> ~/Library/Python would be a good location on OSX, even if the 100% formally correct location would be ~/Preferences/Python (at least of framework builds, unix-style builds may want to follow the unix convention).
> 
> "100% formally" speaking, MacOS behaves like UNIX in many ways.  <http://en.wikipedia.org/wiki/Single_UNIX_Specification#Mac_OS_X_and_Mac_OS_X_Server>

Storing files in unix location will be confusing to many Mac users, Apple has an explicitly documented convention for where to store files and dot-files in the user's home directory aren't part of that convention.

An important reason for storing files in ~/Library/Python of ~/Library/Preferences/Python is that these locations are both logical for mac users and can be navigated to from the Finder without resorting to typing the folder name in "Go -> Go to Folder".

> 
> It's fine to have a mac-pathname-convention-following place for such data, but please _also_ respect the UNIX-y version on the Mac.  The only possible outcome of python on the Mac respect only Mac pathnames is to have automation scripts that work fine on BSD and Linux, but then break when you try to run them on a Mac.  

The stdlib should have APIs for locating common directories, although I must admit that I haven't checked if it actually does have them.  That way you can write automation scripts that work anyware, not just on systems that look a lot like Linux.   

I've written a lot of scripts that had to follow platform conventions on a lot of unix platforms, and those tended to require small changes for every new unix flavor we encountered. Non-linux platforms also have filesystem hierarchy standards, even though they are often not as detailed as the Linux ones and most unix platforms don't have a user-base that is as vocal as the linux packagers when software doesn't follow the conventions.

> There is really no benefit to intentionally avoiding honoring the UNIX conventions.  (For another example, note that although Python resides in /System/Library, on the mac, the thing that's in your $PATH when you're using a terminal is the symlink in /usr/bin/python.)
> 
> Also, no, "~/Preferences" isn't the right place for it either; there's no such thing.  You probably meant "~/Library/Preferences".  I'd say that since ~/Library/Python is already used, there's no particular reason to add a new ~/Library/Preferences/Python location.  After all, if you really care a lot about platform conventions, you should put it in ~/Library/Preferences/org.python.distutils.plist, but I don't see what benefit that extra complexity would have for anyone.

Your right, I meant ~/Library/Preferences, and I'd prefer ~/Library/Python for the reason you meant.   The actual format of the configuration files is not prescribed in any way, and I'd by -1 on storing the preferences in a plist on OSX because that is making live for programmers actively harder.


Ronald
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/71904676/attachment.bin>