Joey Hess wrote: > Andrew Straw wrote: > > To be sure I understand, you're saying this is a bug with setuptools, > > because it autogenerates the /usr/bin/my_script improperly at install > > time when called by "python2.4 setup.py install"? > > No, the problem is, loosely speaking, that python is on crack. > > The order in which versions of python are run is only loosely correlated > to which version of the script is installed, and file timestamps are > somehow involved.
More to the point:
1. With your test script, the last version of python to run wins.
2. Building zhone, the last version of python to run wins.
3. Building winpdb, the *first* version of python to run wins.
4. Unless winpdb is modified not to use dpatch. Then the last
version of python to run wins.
5. *Or* unless the build machine is slow[1], or we just get unlucky[2].
Then, when building winpdb, the last version of python to run wins.
In 4 and 5, as well as my examples with touch, we see that
the install run order matters less than timestamps from the build
run. I hypothesisze that setuptools is doing something like this
to decide which script to install:
- Is one of the build/scripts newer than the others? Install it.
- Do all the build/scripts have the same timestamp? Install the first
one, artitrarily.
- Something to do with the timestamp of the original source file, too?
--
see shy jo
[1] Simulated by making debhelper sleep for 5 seconds after each
call to setup.py.
[2] Ie, I assume there is a race condition here; if the clock ticks
at the right point during the build, the result will change.
(Also probably filesystem dependent.)
signature.asc
Description: Digital signature
