Gnuradio with alternate python

GNU Radio
1

I’m just now getting to a gnuradio project and hadn’t had much of a
chance to dogfood my gnuradio RPM from my repo. Now that I’m getting to
it, all of the examples scripts have #!/usr/bin/env python hardcoded at
the top. I was thinking the build process (which already knows the
appropriate python) should populate all the python scripts with the
correct python?

Otherwise, it looks like I’m going to have to rebuild my RPM and sed all
of the .py files?

2

On Sat, Jun 26, 2010 at 12:32:38PM -0500, Brett L. Trotter wrote:

I’m just now getting to a gnuradio project and hadn’t had much of a
chance to dogfood my gnuradio RPM from my repo. Now that I’m getting to
it, all of the examples scripts have #!/usr/bin/env python hardcoded at
the top. I was thinking the build process (which already knows the
appropriate python) should populate all the python scripts with the
correct python?

Yes, it could. It would probably be best if the “install” step of
“make install” did it while installing them.

Feel free to submit a patch for this based off of the “maint” branch.

Otherwise, it looks like I’m going to have to rebuild my RPM and sed all
of the .py files?

Or, as a workaround, juggle your PATH such that the python you want
comes in front of the python that you don’t want.

Eric

3

Thanks for both your replies. Regarding the PATH fix- in the situation
I’m looking to fix for myself and my users, I’ve got system python 2.4
from RHEL 5/CentOS 5 as /usr/bin/python and my python 2.5 as
/usr/bin/python2.5 (with python25 link). I suppose another choice would
have been to make it /usr/local/bin/python instead, which if I recall my
computing roots, was the place to extra software that departs from the
basic install. In any case, for me the decision to make it side-by-side
was based on sticking to the redhat standard locations. But due to that,
creative path ordering doesn’t help.

I suppose I’m open to suggestion on this one- is the case that people
are compiling gnuradio against a non-default python common enough to
merit the additional step?

If so, would doing either a template sort of approach (put @@PYTHON@@ in
all the gnuradio examples .py files, and use m4 or sed to replace), just
plain using sed, or some other method I’m not thinking of be the best?

If not, I’m open to changing my python25 rpm to relocate the python and
expect users to set the path properly, but I sort of like the “it just
works”.

P. S.

Maybe this is a bad idea or demonstrating a lack of knowledge, but it
seems that its kind of too bad there isn’t some kind of handy little
variant or option of /usr/bin/env that looks at the program name, looks
for an environment variable with a capitalized spelling of the same
name, and uses that path/exe if it exists or falls back to doing the
program name itself. eg setting PYTHON=python2.5 /usr/bin/env -foo
python would run python2.5 instead. Alternatively if the shebang could
support a conditional [ ! -z PYTHON ] … or something.

P.P.S. I won’t reply to the other post about the circbuf message- thanks
for clearing that up, its been a while since I’ve seen that message.

-Brett

4

Somehow distutils solves this problem:
http://docs.python.org/release/2.5.2/dist/node11.html
If you figure out what its calling, perhaps we could port that the
gnuradio build system

What would work is an m4 macro (or hook) that takes the list of python
bin scripts and creates new targets and install rules for each python
script. Basically, make would insert/replace the #!/python_exe_path
line into the top of the file as part of this build process. This new
file would be the one installed.

-JOsh

5

On Sat, Jun 26, 2010 at 10:29 PM, Josh B. [email protected] wrote:

Somehow distutils solves this problem:
2.5 Installing Scripts
If you figure out what its calling, perhaps we could port that the
gnuradio build system
The code that does this can be seen here:
http://svn.python.org/view/python/trunk/Lib/distutils/command/build_scripts.py?revision=77704&view=markup

They use the following regexp:
^#!.python[0-9.]([ \t].*)?$

This handles both things like /usr/bin/env python and
/usr/local/bin/python, which is nice in the general case but not
particularly relevant for GR. They also restrict the match to the
first line of the file, which I think is prudent.

One thing about the @@PYTHON@@ option is it would make the scripts no
longer executable directly from the tree. Arguably you could still
execute them using “python ” so you wouldn’t lose that much,
but it’s something to consider.