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

[ryanvolz]

I'm in the process of adding gr-iio to conda-forge so it can be available as a public conda package (conda-forge/staged-recipes#11688). See also analogdevicesinc/libiio#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]

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.