tahoe-lafs/setuptools-0.6c16dev6.egg/zetuptoolz.txt
Daira Hopwood a823362252 Bump zetuptoolz version (move directory).
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
2015-04-28 18:53:44 +01:00

100 lines
4.1 KiB
Plaintext

This is the "zetuptoolz" fork of setuptools. This version is forked from
setuptools trunk r80621 (which was current at 2010-08-31), with the following
differences:
* Logging outputs more information about which dependencies are being processed.
* Zooko's and David-Sarah's patches for the following bugs and features have been applied:
<http://bugs.python.org/setuptools/issue17>
"easy_install will install a package that is already there"
<http://bugs.python.org/setuptools/issue54>
"be more like distutils with regard to --prefix="
<http://bugs.python.org/setuptools/issue53>
"respect the PYTHONPATH"
(Note: this patch does not work as intended when site.py has been modified.
This will be fixed in a future version.)
<https://tahoe-lafs.org/trac/zetuptoolz/ticket/4>
"python setup.py --help-commands raises exception due to conflict with distribute"
* The following patch to setuptools introduced bugs, and has been reverted
in zetuptoolz:
$ svn log -r 45514
------------------------------------------------------------------------
r45514 | phillip.eby | 2006-04-18 04:03:16 +0100 (Tue, 18 Apr 2006) | 9 lines
Backport pkgutil, pydoc, and doctest from the 2.5 trunk to setuptools
0.7 trunk. (Sideport?) Setuptools 0.7 will install these in place of
the 2.3/2.4 versions (at least of pydoc and doctest) to let them work
properly with eggs. pkg_resources now depends on the 2.5 pkgutil, which
is included here as _pkgutil, to work around the fact that some system
packagers will install setuptools without overriding the stdlib modules.
But users who install their own setuptools will get them, and the system
packaged people probably don't need them.
------------------------------------------------------------------------
* If unpatched setuptools decides that it needs to change an existing site.py
file that appears not to have been written by it (because the file does not
start with "def __boot():"), it aborts the installation.
zetuptoolz leaves the file alone and outputs a warning, but continues with
the installation.
* The scripts written by zetuptoolz have the following extra line:
# generated by zetuptoolz <version number>
after the header.
* Windows-specific changes (native Python):
Python distributions may have command-line or GUI scripts.
On Windows, setuptools creates an executable wrapper to run each
script. zetuptools uses a different approach that does not require
an .exe wrapper. It writes approximately the same script file that
is used on other platforms, but with a .pyscript extension.
It also writes a shell-script wrapper (without any extension) that
is only used when the command is run from a Cygwin shell.
Some of the advantages of this approach are:
* Unicode arguments are preserved (although the program will
need to use some Windows-specific code to get at them in
current versions of Python);
* it works correctly on 64-bit Windows;
* the zetuptoolz distribution need not contain either any
binary executables, or any C code that needs to be compiled.
See setuptools\tests\win_script_wrapper.txt for further details.
Installing or building any distribution on Windows will automatically
associate .pyscript with the native Python interpreter for the current
user. It will also add .pyscript and .pyw to the PATHEXT variable for
the current user, which is needed to allow scripts to be run without
typing any extension.
There is an additional setup.py command that can be used to perform
these steps separately (which isn't normally needed, but might be
useful for debugging):
python setup.py scriptsetup
Adding the --allusers option, i.e.
python setup.py scriptsetup --allusers
will make the .pyscript association and changes to the PATHEXT variable
for all users of this Windows installation, except those that have it
overridden in their per-user environment. In this case setup.py must be
run with Administrator privileges, e.g. from a Command Prompt whose
shortcut has been set to run as Administrator.