Re: Bug#548392: debhelper: python_distutils buildsystem and, setuptools entry_points don't use default python

[Joey Hess]

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.

joey@gnu:~/tmp/winpdb-1.4.6>dh_auto_build >/dev/null 2>&1
joey@gnu:~/tmp/winpdb-1.4.6>touch build/scripts-2.4/*      
joey@gnu:~/tmp/winpdb-1.4.6>dh_auto_install >/dev/null 2>&1
joey@gnu:~/tmp/winpdb-1.4.6>head -1 debian/winpdb/usr/bin/winpdb
#!/usr/bin/python2.4
joey@gnu:~/tmp/winpdb-1.4.6>touch build/scripts-2.5/*
joey@gnu:~/tmp/winpdb-1.4.6>dh_auto_install >/dev/null 2>&1
joey@gnu:~/tmp/winpdb-1.4.6>head -1 debian/winpdb/usr/bin/winpdb
#!/usr/bin/python
joey@gnu:~/tmp/winpdb-1.4.6>touch build/scripts-2.4/*
joey@gnu:~/tmp/winpdb-1.4.6>dh_auto_install >/dev/null 2>&1
hejoey@gnu:~/tmp/winpdb-1.4.6>head -1 debian/winpdb/usr/bin/winpdb
#!/usr/bin/python2.4

--
see shy jo

[Joey Hess]

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.)

[Josselin Mouette]

Le samedi 26 septembre 2009 à 17:55 -0400, Joey Hess a écrit :
> 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.

Actually you are both right; setuptools is on crack for modifying the
shebang, and IIRC distutils does the same.

--
 .''`.      Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `-     future understand things”  -- Jörg Schilling

[Andrew Straw]

Josselin Mouette wrote:

> Le samedi 26 septembre 2009 à 17:55 -0400, Joey Hess a écrit :
>> 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.
>
> Actually you are both right; setuptools is on crack for modifying the
> shebang, and IIRC distutils does the same.
>

setuptools doesn't modify the shebang in the script -- it constructs the
entire script when told to, at install time, on the basis of its
entry_points declaration and the version of python actually being run
(see get_script_header() in setuptools/commands/easy_install.py ).
Therefore order-of-python-running is important for setuptools script
installation, because the last one wins. So, the default python should
run last during the install stage.

I did test and confirm that my patch as originally submitted fixes this
issue.

The winpdb issue is different I am responding directly to #547510 on that.


--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Vincent Danjean-3]

Andrew Straw wrote:
> setuptools doesn't modify the shebang in the script -- it constructs the
> entire script when told to, at install time, on the basis of its
> entry_points declaration and the version of python actually being run
> (see get_script_header() in setuptools/commands/easy_install.py ).
> Therefore order-of-python-running is important for setuptools script
> installation, because the last one wins. So, the default python should
> run last during the install stage.

In the mercurial package, I call sed to ensure a good shebang line:
==================
override_dh_auto_install: $(PYVERS:%=install-python%)

install-python%: build-python%
        python$* setup.py install --root $(CURDIR)/debian/tmp
        # Do not hardcode the python interpreter
        sed -i '1c#!/usr/bin/python' debian/tmp/usr/bin/hg
==================
This setup can probably be adapted for packages needing it.

  Regards,
    Vincent

--
Vincent Danjean       GPG key ID 0x9D025E87         vdanjean@...
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...