Re: [Discuss-gnuradio] Removing '.py' from system path installed Python scripts

[Greg Troxel]

Johnathan Corgan <address@hidden> writes:

> Greg Troxel wrote:
>
>> But that will only really work if the version of python found as 
>> 'python' is the same one as the version gnuradio found when it was 
>> compiled, and the packaging system installs an interpreter as python.
>> In a world with multiple python versions and site-libs this leads to
>> incorrect behavior.
>
> True.  When someone downloads GNU Radio as a tarball, runs configure,
> make, etc., and installs it, everything gets put into the right place to
> be used with the version of Python discovered on the path.  This is a
> good thing, I think, as it covers the most common case.

The case where there is no interpreter called 'python', but one called
'python2.4' is not handled.  This is how pkgsrc works, specifically
avoiding providing 'python', which would change if a new version is
instaled.  I realize that whether this is reasonable is a tough call.

>> See http://www.gnuradio.org/trac/ticket/151
>
> Understood.  There really isn't a clean solution to this, however.  I'd
> be happy if could figure out one that doesn't make the common case more
> difficult.

Given that new versions of python can be installed and made default
(meaning invoked as 'python'), it's necessary to bind the scripts to the
same version of python used to build .so modules and install .py files
in site-packages.  I think it can be done quite cleanly by either of the
two methods in the ticket, in the software engineering aesthetics sense,
and that the modify-on-install avoids a lot of non-local hair.

Specifically, add a new script install-py that is generated from
install-py.in via configure that has

#!/bin/sh
# really  this might need to parse install args better
INSTALLTMP=/tmp/$1.install.$$
sed -e "s,/usr/bin/env python,@PYTHON@," < $1 > $INSTALLTMP
install -m 555 $INSTALLTMP $2

and then have the install-script rule use this instead.

I looked in the tree, and it seems it should go at top level alongside
py-compile.