Gr-howto-write-a-block refactored

GNU Radio
1

Hi folks,

I just committed a change to gr-howto-write-a-block that now has it
install in the “howto” python namespace instead of in the
“gnuradio.howto” namespace.

This allows howto (or other things based on it) to install under a
non-system prefix. For systems using binary GR packages, this means
that user written “out of tree code” will not have a conflict with the
“gnuradio” namespace.

From a high level point of view, this changes means that if you’re
using these blocks, you would now import them using

import howto

instead of

from gnuradio import howto

Eric

2

On Thu, Mar 04, 2010 at 07:15:19AM -0800, Eric B. wrote:

instead of

from gnuradio import howto

Hi Eric and list,

while this makes some things easier, I’m wondering if it wouldn’t be
nice to keep the Python modules in some kind of GR-specific namespace.

Take the howto example: imagine a new user tries to install it just to
see
what happens. It’s not completely unreasonable that another piece of
software would have a Python module called ‘howto’, which might result
in collisions. The same goes for other modules (I’ve written one called
‘specest’, this could be anything related to spectral estimation, the
name doesn’t imply any GNU Radio).

If I use the howto example as a template for writing a new module (and I
assume most people do), do I need to make sure the name doesn’t clash
with any other Python module? Or do I give it a name like
‘gr-modulename’?

Frankly, I don’t really know that much about the whole auto-stuff
internals, and in my local configuration I’ve never had any conflicts,
either, so I shouldn’t be ranting about code changes. But it somehow
doesn’t seem right to install modules right into some system path.
The ‘old’ method also had the advantage that I couldn’t lose track of
my GR stuff, e.g. if I had to nuke my installation for some reason I’d
simply delete $PYTHONLIBS/gnuradio and if I had installed e.g. howto,
it would vanish as well.

Just my two Euro-cents…

Martin

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

3

On Mon, Mar 15, 2010 at 12:56, Martin B. [email protected]
wrote:

while this makes some things easier, I’m wondering if it wouldn’t be
nice to keep the Python modules in some kind of GR-specific namespace.

Take the howto example: imagine a new user tries to install it just to see
what happens. It’s not completely unreasonable that another piece of
software would have a Python module called ‘howto’, which might result
in collisions. The same goes for other modules (I’ve written one called
‘specest’, this could be anything related to spectral estimation, the
name doesn’t imply any GNU Radio).

Locally compiled GNU Radio is installed into /usr/local/lib. So user
compiled modules can extend the gnuradio namespace in Python by also
installing in /usr/local/lib/…/gnuradio/. However, binary
installations of GNU Radio are becoming more and more frequent, and
install into /usr/lib. The filesystem hierarchy standard requires all
locally compiled software to be in /usr/local, so it was not possible
to install the howto module with a binary install of GNU Radio.

This change to the out-of-tree configuration Eric noted fixes this.
While I see your point about global namespace conflicts, this would
only really be with other locally compiled packages in /usr/local.

Johnathan