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

Michael Foord fuzzyman at voidspace.org.uk
Mon Aug 2 11:48:39 CEST 2010


On 02/08/2010 07:18, Ronald Oussoren wrote:
> 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".
>
>    

Really? As a Mac user I have never edited (or even looked at) files in 
~/Library. I would never think of going there for finding config files 
to edit. However in my home directory I have:

     .Xauthority
     .Xcode
     . CFUserTextEncoding  - (an Apple encoding configuration for Core 
Foundation)
     .bash_profile
     .cups
     .dropbox
     .dvdcss
     .filezilla
     .fontconfig
     .hgrc
     .idlerc
     .ipython
     .mono
     .netbeans
     .parallels_settings
     .pypirc
     .wingide3

Actually that is just a small selection of the .config files/directories 
in my home directory. It is certainly *a* standard location for config 
files on the Mac, including some Apple software (XCode) and Python 
applications.

My preference would  be to follow this established and well used convention.

Michael

>> 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
>    
>>      
>    
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100802/9a1bd5fd/attachment.html>


More information about the Python-Dev mailing list