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.)
Attachment:
signature.asc
Description: Digital signature