[Python-Dev] setuptools in 2.5.

[Jim Jewett]

M.-A. Lemburg wrote:

>There's really nothing wrong with the standard distutils
>two step process:

>1. download and unzip the source file

On windows, the closest thing to a standard unzip is winzip.

I have recently found several zip files aimed at windows users which
winzip could not open, though python's tarfile module could.  So the
unzip isn't always trivial.

>2. run "python setup.py install"

setup.py isn't a unique enough name to convince me that things are
easily reversed or repeated.  The distutils are complex enough that my
concern doesn't go away.  (Whether setuptools will be clear enough or
documented enough to actually solve this, I don't yet know.  I have
high hopes.)

Phillip J. Eby wrote:

> Such packages may have customized their installation process
> by extending the distutils, *without* overriding get_outputs().  Since few
> people actually use the --record option for anything important, nobody
> notices when it breaks.

I just searched through the (2.4.2) documentation, and could find no
reference to either get_outputs or --record.  I also looked through
the source, and couldn't find any reference to --record.  (I later
found one in bdist_rpm, but "build a binary for Red Hat Linux" isn't a
natural thing for anyone not on Linux to even try.)

When I did a grep (which I wouldn't do unless I already knew I needed
to worry about it), I finally found a few references in install.py
which boiled down to "nothing happens, but you could get a list of
files if you went through enough contortions".  This looks more like a
debugging aid than something I would have to worry about.

> As for --install-data, just put your data in the packages and use Python
> 2.4's ability to install package data, or one of the pre-existing distutils
> extensions that beat install_data over the head to make it install the data
> with the packages.

Use of a third-party extension (that isn't mentioned in the docs) is
hardly intuitive.  If it is really required, that is far more
intrusive than the stdlib changes setuptools makes.  (Would it only
intrude on the packager, at least?  But then how could he or she be
confident that the package would work on someone else's box?)

-jJ