[Python-checkins] CVS: python/nondist/peps pep-0250.txt,1.2,1.3

[Barry Warsaw]

Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv12840

Modified Files:
	pep-0250.txt 
Log Message:
Paul's latest revision, marked Finish, with minor formatting fixes.
Paul changed the name of the PEP so this will be reflected in PEP 0.


Index: pep-0250.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0250.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** pep-0250.txt	2001/06/05 17:01:55	1.2
--- pep-0250.txt	2001/08/14 22:23:18	1.3
***************
*** 1,9 ****
  PEP: 250
! Title: Using site-packages on All Platforms
  Version $Revision$
  Author: gustav@morpheus.demon.co.uk (Paul Moore)
! Status: Draft
  Type: Standards Track
! Created: 2001-03-30
  Python-Version: 2.2
  Post-History: 30-Mar-2001
--- 1,9 ----
  PEP: 250
! Title: Using site-packages on Windows
  Version $Revision$
  Author: gustav@morpheus.demon.co.uk (Paul Moore)
! Status: Final
  Type: Standards Track
! Created: 30-Mar-2001
  Python-Version: 2.2
  Post-History: 30-Mar-2001
***************
*** 19,23 ****
  
      This PEP proposes that the site-packages directory should be used
!     uniformly across all platforms for locally installed modules.
  
  
--- 19,23 ----
  
      This PEP proposes that the site-packages directory should be used
!     on the Windows platform in a similar manner.
  
  
***************
*** 27,33 ****
      include a directory suitable for users to install locally
      developed modules.  The "expected" location appears to be the
!     directory containing the Python executable itself.  Including
!     locally developed code in the same directory as installed
!     executables is not good practice.
  
      Clearly, users can manipulate sys.path, either in a locally
--- 27,34 ----
      include a directory suitable for users to install locally
      developed modules.  The "expected" location appears to be the
!     directory containing the Python executable itself.  This is also
!     the location where distutils (and distutils-generated installers)
!     installs packages.  Including locally developed code in the same
!     directory as installed executables is not good practice.
  
      Clearly, users can manipulate sys.path, either in a locally
***************
*** 72,79 ****
              sitedirs == [prefix, makepath(prefix, "lib", "site-packages")]
  
!     Changes would also be required to distutils, in the sysconfig.py
!     file.  It is worth noting that this file does not seem to have
!     been updated in line with the change of policy on the Macintosh,
!     as of this writing.
  
  
--- 73,87 ----
              sitedirs == [prefix, makepath(prefix, "lib", "site-packages")]
  
!     Changes would also be required to distutils, to reflect this change
!     in policy. A patch is available on Sourceforge, patch ID 445744,
!     which implements this change.  Note that the patch checks the Python
!     version and only invokes the new behaviour for Python versions from
!     2.2 onwards. This is to ensure that distutils remains compatible
!     with earlier versions of Python.
! 
!     Finally, the executable code which implements the Windows installer
!     used by the bdist_wininst command will need changing to use the new
!     location.  A separate patch is available for this, currently
!     maintained by Thomas Heller.
  
  
***************
*** 86,90 ****
      - Both the current location (sys.prefix) and the new directory
        (site-packages) are included in sitedirs, so that .pth files
!       will be recognized in either location.
  
      - This proposal adds a single additional site-packages directory
--- 94,98 ----
      - Both the current location (sys.prefix) and the new directory
        (site-packages) are included in sitedirs, so that .pth files
!       will be recognised in either location.
  
      - This proposal adds a single additional site-packages directory
***************
*** 97,119 ****
        having two separate package directories.
  
!     - If users want to keep DLLs in a single location on Windows,
!       rather than keeping them in the package directory, the DLLs
!       subdirectory of the Python install directory is available for
!       that purpose. Adding an extra directory solely for DLLs should
!       not be necessary.
  
  
  Open Issues
  
!     - There have been no comments on this proposal from non-Windows
!       users. In the absence of such comments, it is assumed that there
!       will be no adverse effects on such platforms caused by the
!       proposed change. (The author knows of no reason why there should
!       be).
  
!     - There could be issues with applications which embed Python. To
!       the author's knowledge, there should be no problem as a result
!       of this change. Again, there have been no comments (supportive
!       or otherwise) from users who embed Python.
  
  
--- 105,127 ----
        having two separate package directories.
  
!     - If users want to keep DLLs in a single location on Windows, rather
!       than keeping them in the package directory, the DLLs subdirectory
!       of the Python install directory is already available for that
!       purpose. Adding an extra directory solely for DLLs should not be
!       necessary.
  
  
  Open Issues
  
!     - Comments from Unix users indicate that there may be issues with
!       the current setup on the Unix platform.  Rather than become
!       involved in cross-platform issues, this PEP specifically limits
!       itself to the Windows platform, leaving changes for other platforms
!       to be covered inother PEPs.
  
!     - There could be issues with applications which embed Python. To the
!       author's knowledge, there should be no problem as a result of this
!       change. There have been no comments (supportive or otherwise) from
!       users who embed Python.