[Python-Dev] PEP 370 - per-user scripts directory on Windows

Paul Moore p.f.moore at gmail.com
Tue Feb 10 13:38:25 CET 2015


tl;dr - Having a shared per-user scripts directory on Windows
(%APPDATA%/Python/Scripts) causes a number of potential issues when
users install the same package in multiple Python versions. I'd like
to suggest that this be changed to a versioned directory
(%APPDATA%/PythonXY/Scripts) to match all other Python directories on
Windows.

This issue originally started as a discussion on the pip tracker
around making --user the default for pip. See
https://github.com/pypa/pip/issues/1668 for details. However, because
the user scripts directory is shared across all Python versions, this
poses a number of issues:

1. If we "pip install" something like pytest, which version gets the
name "py.test.exe" works on a "last install wins" basis, which is not
ideal.
2. The above behaviour (and more generally the shared site scripts
directory) does not respect the user's "Make this my default Python"
choice from the installer, in potentially surprising ways.
3. Uninstalling a package which has been installed in 2 pythons will
likely fail, because either the checksum of an installed script does
not match what's in the RECORD file, or because a file that should be
present has already been uninstalled via a different Python version
[1].

I suggest that the per-user scripts directory should be versioned, in
exactly the same way as every other Python-related directory on
Windows. So we would have %APPDATA%\PythonXY\Scripts alongside
%APPDATA%\PythonXY\site-packages. This is a familiar pattern for
Windows users, and should not cause significant confusion.

It would be good to get this added for Python 3.5, *before* making
user installs the default (needed for 3.5 as the default install
location for 3.5 will need admin privileges to write).

Some additional points:

1. This is a Windows-specific proposal, because Unix has always had
scripts installed in a common location (e.g., /usr/local/bin) and
commonly-understood solutions already exist on that platform
(versioned command names, python -m, system package management, etc).
However, these solutions would be a significant change for Windows
users.

2. Packages which recommend a user install specifically so that their
commands are available regardless of which Python is on PATH would
have to find an alternative solution. I doubt there are many such
packages, but this should be considered.

3. This proposal does not affect the Python launcher for Windows.
People using the launcher exclusively may be currently using "py -m
pip" (or whatever) to launch applications, in which case the change of
user script directory won't affect them.

4. I am not aware of any tools that rely on the location of the user
scripts directory. Such scripts should be using sysconfig in any case.

5. The problems mentioned exist in current Python versions, but
haven't been flagged up, presumably because very few people use the
user install location - precisely because it's not the default in pip.
Changing the pip default would cause more people to encounter the
issues, but I don't propose backporting this change, as it's not a bug
fix. If it becomes a major issue for pip users on older versions, we
can either reconsider this, or pip can decide on its own workaround.

Comments? If this is acceptable, I would be willing to prepare a patch
for Python 3.5 implementing this.

Paul

[1] Checking of checksums is not currently implemented, AFAIK, but it
is the purpose of the checksums in the RECORD file, and could be
implemented in future versions of pip.


More information about the Python-Dev mailing list