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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
