Spring clean to enable contributions


After building Sonic Pi on my own workstation, I’ve spent the last few days thinking how to make it easier for others to make contributions to the project. As Sam has said on this forum, he has been facing a resource shortage for the last year or so, where his limited time is split between either working on Sonic Pi or doing workshops, talks and performances to raise awareness of the project and put beans on the table. This leaves no time for improving the developer experience and managing the project - with the result that new contributors face a steep learning curve, and existing contributors may lose motivation or become frustrated.

I would like to make it easier to access Sonic Pi as a potential contributor, in two ways: firstly, to make sure all platforms are served with up-to-date packages. 3.1 is currently packaged for Window and Mac, but Raspbian lags at 2.10, and desktop Linux is officially unsupported, with a few outdated packages scattered across third-party repositories. As a long-term Linux developer, I am certainly biased, but I believe that Linux users often become contributors, and the gateway is an available package to become a user.

Secondly, I want to make it easy to build and hence hack on Sonic Pi. Fearsome dependencies have to be tamed and built first, as it’s based on Supercollider, Ruby, Qt and Erlang. The codebase is currently something of a rabbit warren, with many deeply branching tunnels, chambers of last season’s carrots, and communicating cross-passages. Working on one component requires bunny lore in case it disturbs a support somewhere else and causes a collapse. There is no single build system, instead, there is a sheaf of platform/distribution/version-specific scripts provided by plucky individuals, all doing the same thing, if they are not stale. There is no install target, so packagers have to figure out what goes where, or just hold their noses and bang the whole tree into /opt.

Isn’t this a fairly mordant first post to the Development category? What is he going to do about it, you ask…

  1. The first thing the project needs is a simpler, flatter codebase with less coupling between components.

  2. This enables the creation of a cross-platform build system, which separates the installation of Sonic Pi’s dependencies from its build

  3. This will simplify correct packaging of the build, and enable curious hackers to clone the repository and build Sonic-Pi locally and maybe experiment with changing the code. It should also save existing contributors’ time and effort.

Drilling down into 1), I intend to:

  • Remove unused components (html client) and cruft
  • Squash the tree by function of each component
  • Identify shared stuff and push that up the tree, removing coupling between components
  • Separate build utilities from the server code
  • Use Bundler to manage gems instead of keeping vendor copies in the tree

Following the motto “Move fast and break things” there is a first stab at this in my fork. It probably breaks a lot of things including Mac and Windows for now, but I will loop back round once I have a CMake build system up.



Not sure if you’ve already seen it, and not sure how relevant it still is, but there was a PR opened a few years ago which generated some discussion about using bundler.


I hadn’t seen that (probably for the best), but it looks like the discussion in that (and the linked Linux Packaging PR #1864) mention many of the problems I’m trying to solve. I worked on a packaged Ruby CLI application recently, and the approach we took on Linux was to run bundler in --standalone mode during the package build, setting up the bundled gems so no bundler is required at runtime. For Windows and Mac builds, I would insert ‘grab Ruby binaries and bundler’ and run bundle install using those, before packaging them and the gems, deleting specs, examples and other ancillary stuff as I do so.


CMake build system is up, finds dependencies, builds the scheduler, bundles for the server, builds the gui: https://github.com/wstephenson/sonic-pi/tree/cmake-all-the-things
Still to-do: doc and i18n, Windows and Mac support.

Now I’ll dare to go check whether there’s an existing cmake PR…