[Python-Dev] Fixing #7175: a standard location for Python config files

[Michael Foord]

On 12/08/2010 11:18, Steve Holden wrote:
> On 8/12/2010 5:50 AM, Tim Golden wrote:
>    
>> On 11/08/2010 16:22, Éric Araujo wrote:
>>      
>>> It would be nice to define one standard location for config files used
>>> by stdlib modules, and maybe also by third-party programs related
>>> closely to Python development (testing tools, static code checkers and
>>> the like), in a way that doesn’t clutter the user home directory with a
>>> dozen dotfiles while still being easily found.
>>>
>>> (The Unix notions of dotfiles and home directory have to be adapted to
>>> use non-dotfiles in some standard place on various Windows. The Mac
>>> experts disagree on the right directory to use.)
>>>        
>> The canonical place on Windows (per Microsoft [1]) is:
>>
>> for roaming data: the Application Data folder (exposed as the
>> APPDATA env var and as CSIDL_APPDATA pre-Vista and the
>> FOLDERID_RoamingAppData Known Folder on Vista+).
>>
>> for non-roaming data: the local app data (CSIDL_LOCAL_APPDATA
>> or FOLDERID_LocalAppData)
>>
>> The obvious difference is whether a user expects the data to be
>> available for the same account on a different computer. At present,
>> the user site packages are held under %APPDATA%\Python\Pythonxx,
>> ie are considered roaming.
>>
>> Unfortunately, the canonical place is not always the place most
>> used. Especially since the convention under *nix is to place dotfile
>> or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so
>> various locations are considered $HOME, including (but not limited
>> to):
>>
>> * the directory pointed to by %HOME%
>> * the directory pointed to by %USERPROFILE%
>> * the "My Documents" shell folder
>>    (often, but not always, %USERPROFILE%\My Documents)
>> * c:\ (no: really)
>> * the NT profile home directory (typically a mapped share)
>>
>> Dotfiles are possible on Windows; the issue is that they can't
>> be created within the shell (ie within Windows Explorer). They
>> can be renamed, edited, etc without issue, so it's not much of
>> a problem. They can be created by any program which can call
>> CreateFile -- including Python, obviously.
>>
>> TJG
>>
>> [1] http://support.microsoft.com/kb/310294
>>      
> Didn't we have this discussion when per-user libraries came up?
> Shouldn't we be using a subdirectory of that location? We ruin the risk
> of Python becoming distributed so finely it becomes impossible to change
> things, what with per-user libraries, per-version shared binaries,
> per-user-per-version library configuration files and the rest.
>
>    

User editable configuration files are very different from libraries. The 
per user site-packages folder *should* be hidden somewhere out of the 
way where you can get at them if you want them but won't stumble across 
them all the time. e.g. AppData on Windows.

For files we expect the user to be able to edit we shouldn't go out of 
our way to make them hard or inconvenient to find.

> One might make a case that all configuration data should be stored in a
> single SQLite database (with a suitable API to hide the relational
> nature of the store).
Yay - let's recreate the Windows registry! A binary blob only editable 
with special tools, we know how much users love that.


Michael

>   Then at least there would only be one file no
> matter how many versions of Python were installed. Seriously. We are
> already spending enough time doing stat calls on non-existent directories.
>
> regards
>   Steve
>
> PS: Then we can start putting the libraries themselves in the database.
> That works really well.
>    


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