At the GNU Radio Hackfest that took place at Virginia Tech in early June, a few developers introduced a cool new project they had been working on called "PyBOMBS". It has since been announced on the GNU Radio list, and more people are beginning to experiment with it.
There is already a wiki page on the GNU Radio website describing the basics of how to use it, so I won't repeat all of that here, but I thought it would be useful to talk about why PyBOMBS is so exciting.
So, what is it?
The easiest way to understand PyBOMBS is to think of it as a package management system, similar to those that you use on most *nix OSes: apt (dpkg), pacman (ABS), yum (RPMs), etc. Of the plethora of systems out there, PyBOMBS is probably most similar to Gentoo's portage, which manages Gentoo 'ebuild' packages. I make this link because, like Gentoo, PyBOMBS lets you do everything from source, if you so choose (it also let's you install things using 'apt' or 'yum').
Like the package managers mentioned above, PyBOMBS consists of a number of different parts, including:
- Package recipes (called LWRs, or light-weight recipes, in PyBOMBS lingo).
- Dependency checking & resolving.
- An automated build system.
- Management of available & installed packages.
What problems does it solve?
PyBOMBS makes a lot about managing GNU Radio installs and dependencies much easier, gives you quick control over versioning problems, and makes it much easier to benefit from out-of-tree modules that other people are hacking on. Let's talk about each of these a bit more.
GNU Radio is a complex framework, and is designed in a modular fashion. If you check out the source tree, you'll see a series of independent modules (indeed, they are built separately during a GNU Radio build), generally named gr-<name> - eg., 'gr-analog', 'gr-digital', 'gr-uhd', etc. Generally, when someone is developing new awesome functionality for GNU Radio, it goes into a module. KIT's work on gr-specest is a great example.
To keep the project source tree a manageable size, though, most of the modules that are created will never be part of the core source tree. This isn't because they aren't valuable contributions - but if every module ever made was added, the codebase would explode and become wholly unmanageable, leading to utter misery for Tom Rondeau and Jonathon Corgan. Thus, most modules are maintained "out-of-tree", i.e., outside of the primary GNU Radio source tree.
This introduces a new problem, though: how do you find out what OOT modules are available? How do you build them? Many have extra dependencies, in addition to GNU Radio's. The solution right now is to handle each one individually and manually, handling the logistics of it all as necessary.
PyBOMBS makes this all super easy. All you need to build an OOT module with your GNU Radio install is a recipe, and the developers have already provided recipes for most popular modules - there are 107 as of 06/29/13. Here is an example of the recipe for Balint Seeber's supremely awesome gr-baz module:
category: common depends: gnuradio uhd curl cmake armadillo gr-compat source: git://https://github.com/balint256/gr-baz gitbranch: master inherit: cmake
Pretty light-weight, right? ;)
Installing an OOT module is very straightforward - with a single command, PyBOMBS will fetch any dependencies necessary, install them, and then fetch / build / install your new module for your hacking enjoyment.
The Module & App Stores
People sometimes ask, "Why doesn't GNU Radio have an appstore?" It sounds silly at first, but if you think about it, it actually would be incredibly useful. And, really, PyBOMBS is the perfect way to go about implementing it.
Taking the 'package management' comparison a bit further, PyBOMBS is actually incredibly similar to management systems like Perl's CPAN, and Ruby's Gems. These systems not only provide you with a way to build & install modules, but also provide a means to search for modules other people have developed so that you, as Perl's CPAN website states, "Stop reinventing wheels and start buildin space rockets".
GNU Radio originally had CGRAN for this purpose, but it has really fallen into disuse. It was never advertised very well, but even if it had been, it's usefulness has declined significantly since the rise of git and Github. Most people are sharing their code on Github or bitbucket these days - not by uploading tarballs of source code to websites like CGRAN or SourceForge. The latter method is not only antiquated, but disconnects you from the development of the software and its authors, which are some of the primary advantages of FOSS!
Versioning and chroot'd Installs
(NOTE: Yes, I realize what I describe below isn't a complete 'chroot' with a mounted /proc, /dev, etc., but roll with 'chroot' as a general verb for now, and it'll make everything easier =) )
As with any complex software project with complex dependencies, there are occasionally versioning issues. By this I mean something changes or breaks in a new version of some dependency library, users update their computer and get the new version, and then suddenly discover that GNU Radio no longer works.
One good example of this is Boost. The [Boost C++ libraries](http://en.wikipedia.org/wiki/Boost_(C%2B%2B_libraries) are incredible, and used very heavily in GNU Radio. Unfortunately, though, there are occasionally API changes that catch us off-guard, and as a result, if a user gets a breaking Boost update through their OSes package repositories (Ubuntu, Fedora, etc.,), it will break GNU Radio for him / her. This actually happened when Ubuntu 13.04 was released, and the new version of Boost available for that OS was incompatible with GNU Radio. See here for the list discussion.
Another example is ZeroC ICE. There is actually a bug in the most recent version of ZeroC ICE available in Ubuntu's repositories that prevents compiling projects pulling in ICE... such as Tom's gr-ctrlport work. Ouch.
But, what happens when your OS actually requires the newest version of that library for some critical program? You have to choose between a working OS, a working GNU Radio install, or trying to maintain separate installs. Ugly.
PyBOMBS solves all of this for us by allowing you to very easily create chroot'd installs of GNU Radio and all dependencies. Instead of trying to manually maintain package versions of important libraries on your computer, which will likely result in a serious conflicts down the road, you can create a separate install of dependencies, GNU Radio, and OOT modules in a contained directory.
You could, of course, have done this manually before. PyBOMBS just lets you do this without wanting to drop-kick your computer out of the window. This is actually very similar to things like the Ruby Version Manager (RVM) - which exists for exactly the same reason.
You can obviously extend this even further. If you want to maintain separate versions of GNU Radio on your system for compatibility testing, say, GNU Radio 'master' and GNU Radio 'next', this is now a cake-walk.
PyBOMBS is still early software, and development is on-going. It's already very usable and very useful, but it's definitely beta.
All of the development is happening on Github, of course, and it's essentially all Python. Patches and contributions are welcome!
Happy hacking =)