search

analogdevicesinc / gr-iio

IIO blocks for GNU Radio
GNU General Public License v3.0
94 stars 62 forks source link

Guidance on python packaging with GR 3.8/conflict with libiio bindings #85

Open ryanvolz opened 4 years ago

ryanvolz commented 4 years ago

I'm in the process of adding gr-iio to conda-forge so it can be available as a public conda package (https://github.com/conda-forge/staged-recipes/pull/11688). See also https://github.com/analogdevicesinc/libiio/issues/525. This is in support of getting a nice SDR stack available with conda to make installation easier and provide wider access within my own community (geospace radio science) and in general. (If anyone else is interested in supporting this with me, I'd be happy to collaborate.)

I'm packaging the upgrade-3.8 branch since I need compatibility with the GNU Radio 3.8 package that's already in conda-forge. With this branch, the Python package for gr-iio is, by default, installed into the environment's site-packages directory as "iio". This conflicts with libiio's Python package which is also called "iio" and installed to the same place. So my question is, how should this work? Should I be tweaking CMake settings to install to separate directories (e.g under "gnuradio" for gr-iio), or is it customary to rename one of these? Apologies if I've missed documentation or a discussion somewhere; I'm relatively new to using libiio in particular.

As an aside: are there near-term plans to tag a release that is compatible with GNU Radio 3.8? (Or is GREP 0017 intended to supplant any separate release?) I ask because conda-forge much prefers to package from a released tarball and not a hash in a git repository, and I'm not sure yet if that will be a blocker for merging the package at all.

tfcollins commented 4 years ago

Yes, this is an ongoing debate we have. We used to get around this by putting the swig components into gnuradio\iio instead of just iio, but this usually cased more issues than it solved. Primarily for those who install from apt. Upstreaming gr-iio solves all of the issues but we don't have control over the process.

With the current code for gr3.8, there is no workaround without modifying some source.

We may go back to the old folder structure used in gr3.7 but it's still under discussion internally. We have a few projects that rely upon gr-iio, so moving this can have consequences.