Adding conda support

[ryanvolz]

I've been off on a parallel track for a little while building GNU Radio and some friends as conda packages, with recipes being a part of the community-supported conda-forge distribution. The CondaInstall page on the GNU Radio wiki goes into some more detail about how this works and why it's useful. Conda and conda-forge fill a similar niche as PyBOMBS (recipes for installing/building software, prefixed environment management), but there are enough differences that I think it would be worthwhile to figure out how they can work together. I'm interested in putting in that work, but I as-yet know little about PyBOMBS and think it would be helpful to get some community feedback on what could actually be done.

I can see a couple areas for interoperability:

1. Add conda and the conda-forge channel as a source of binary packages that can be installed by PyBOMBS.

On Linux, this might not have much benefit over distribution-supplied binaries, but sometimes the provided software versions could be a little newer and it would be an alternative to building from source if those newer versions are desired. In the future, if a broader sample of OOTs are built for conda, it could provide binaries for those that are otherwise unavailable.

On macOS, conda would provide similar functionality to Homebrew or MacPorts, except that the packages are binaries and not source builds.

On Windows, this would be a huge win for addressing #551 in that it provides a binary source for GNU Radio's dependencies and would also be a method for installing binaries of GNU Radio and OOTs themselves.

Going the other direction, PyBOMBS fills a hole with the conda binary packages: it's not realistic to make conda packages for every OOT under the sun (although... see 2.), so when source builds are required PyBOMBS can do what it does best and make those builds easier on end users. I don't know if there are even any changes to PyBOMBS necessary to make this work well (perhaps detecting that it's running within a conda environment and using it as the default prefix), but the goal would be to ensure PyBOMBS works inside a conda environment for building from source. With this working, sticking PyBOMBS into my radioconda installers would be a great way to get new users up and running on Linux, macOS, or Windows and have the full breadth of OOTs available at their fingertips.

2. Use the information in a PyBOMBS recipe to jump-start or even fully automate creating a corresponding conda recipe.

The goal of this would be to make it easier to get more OOT binary packages added to conda-forge so that more of the ecosystem can be installed as binaries. I don't know if this is a feature that should be a part of PyBOMBS proper or an external tool. The conda ecosystem already has similar tools for creating conda recipe skeletons from PyPI packages (e.g. Grayskull), and this would be helpful for creating/maintaining recipes for GNU Radio OOT modules in the same way.

---

I think (1) is the place to start, given that there are already a lot of examples to follow for adding a new packager. It's what I'll start playing around with pending any feedback anyone here might have.

So to anyone more familiar with PyBOMBS than me (probably everyone reading this), do these things sound reasonable, implementable, and desirable? Are there pain points that I should be aware of that I'm not anticipating? I also welcome help from any one who's interested, and I'll be happy to answer questions about conda for anyone unfamiliar with the details. Otherwise, I'll probably be back with a PR in a little while. Cheers!

[dkozel]

@mbr0wn and @argilo are probably the best qualified to give feedback and advice. The (likely unacheivable) goal of making all public OOTs installable on all OSs is a great one to strive for and I think the combo of PyBOMBS and Conda is the best chance I've seen of it happening.