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

Steve Holden steve at holdenweb.com
Thu Aug 12 12:18:27 CEST 2010


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.

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). 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.
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010    http://djangocon.us/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/



More information about the Python-Dev mailing list