Abstract

The standard Python distribution includes a directoryLib/site-packages, which is used on Unix platforms to holdlocally installed modules and packages. Thesite.py moduledistributed with Python includes support for locating othermodules in the site-packages directory.

This PEP proposes that the site-packages directory should be usedon the Windows platform in a similar manner.

Motivation

On Windows platforms, the default setting forsys.path does notinclude a directory suitable for users to install locallydeveloped modules. The “expected” location appears to be thedirectory containing the Python executable itself. This is alsothe location where distutils (and distutils-generated installers)installs packages. Including locally developed code in the samedirectory as installed executables is not good practice.

Clearly, users can manipulatesys.path, either in a locallymodifiedsite.py, or in a suitablesitecustomize.py, or even via.pth files. However, there should be a standard location for suchfiles, rather than relying on every individual site having to settheir own policy.

In addition, with distutils becoming more prevalent as a means ofdistributing modules, the need for a standard install location fordistributed modules will become more common. It would be betterto define such a standard now, rather than later when moredistutils-based packages exist which will need rebuilding.

It is relevant to note that prior to Python 2.1, the site-packagesdirectory was not included insys.path for Macintosh platforms.This has been changed in 2.1, and Macintosh includessys.path now,leaving Windows as the only major platform with no site-specificmodules directory.

Implementation

The implementation of this feature is fairly trivial. All thatwould be required is a change tosite.py, to change the sectionsetting sitedirs. The Python 2.1 version has:

ifos.sep=='/':sitedirs=[makepath(prefix,"lib","python"+sys.version[:3],"site-packages"),makepath(prefix,"lib","site-python")]elifos.sep==':':sitedirs=[makepath(prefix,"lib","site-packages")]else:sitedirs=[prefix]

A suitable change would be to simply replace the last 4 lines with:

else:sitedirs==[prefix,makepath(prefix,"lib","site-packages")]

Changes would also be required to distutils, to reflect this changein policy. A patch is available on Sourceforge, patch ID 445744,which implements this change. Note that the patch checks the Pythonversion and only invokes the new behaviour for Python versions from2.2 onwards. This is to ensure that distutils remains compatiblewith earlier versions of Python.

Finally, the executable code which implements the Windows installerused by thebdist_wininst command will need changing to use the newlocation. A separate patch is available for this, currentlymaintained by Thomas Heller.

Notes

• This change does not preclude packages using the currentlocation – the change only adds a directory tosys.path, itdoes not remove anything.
• Both the current location (sys.prefix) and the new directory(site-packages) are included in sitedirs, so that.pth fileswill be recognised in either location.
• This proposal adds a single additional site-packages directoryto sitedirs. On Unix platforms, two directories are added, onefor version-independent files (Python code) and one forversion-dependent code (C extensions). This is necessary onUnix, as the sitedirs include a common (across Python versions)package location, in/usr/local by default. As there is no suchcommon location available on Windows, there is also no need forhaving two separate package directories.
• If users want to keep DLLs in a single location on Windows, ratherthan keeping them in the package directory, the DLLs subdirectoryof the Python install directory is already available for thatpurpose. Adding an extra directory solely for DLLs should not benecessary.

Open Issues

• Comments from Unix users indicate that there may be issues withthe current setup on the Unix platform. Rather than becomeinvolved in cross-platform issues, this PEP specifically limitsitself to the Windows platform, leaving changes for other platformsto be covered in other PEPs.
• There could be issues with applications which embed Python. To theauthor’s knowledge, there should be no problem as a result of thischange. There have been no comments (supportive or otherwise) fromusers who embed Python.

Copyright

This document has been placed in the public domain.