This is a story of how we cobbled together a collection of free build bot apps for pygame - the python game development library. So the internet could build our software for us. Hey, many Free and Open Source projects might find this useful too... I thought... so here is the story.
Continuous integration is great. It's even greater when you have dozens of platforms, and many versions of a python interpreter you need to have things run on. It means your python 2 contributors on linux can see that their change broke an OS X build on python 3. Every change you make things get built for all the different platforms, and tests are run, installers are built, and packages are made.
In 2008 the pygame project had the great fortune for 'thorbrian' and some other contributors to set up a build page for Windows, and Mac. Two platforms which had sort of tricky python build setups not so commonly understood in the FOSS world.
"The Spectacularly Adequate Automated Pygame Build Page" was born. And it was spectacularly adequate. Everyone rejoiced.
So now people could download builds when we made changes. Then they could test them on their weird windows machine with directx N, and some strange AMD card they found in a rubbish bin somewhere.
Occasionally it would connect to the SVN code repository (yes, it was that old) and it would grab the code and do a build. Awesome. This was some years before things like TravisCI provided free infrastructure to the world (massive shoutout and thankyou the the travis mob).
But at some point a few years later the machines stopped building things. They crashed. Unfortunately no one was able to replace them.
So, a couple of years ago we began the slow process of finding a replacement. There were a few missteps. Of course! Trying to setup our own virtual machines. That worked for a little while. But VMs were changing at such a rate, and no one really had space to host machines that worked all that well. We even started on a project to let anyone upload a build. But this never was finished. We tried to get in contact with a few other python projects, and open source projects but no one was all that interested in replying to emails it seems.
So our project sort of stalled. This wasn't the only reason, but one big one. Without builds being made automatically we went back into the world of things breaking all the time, and waiting for random do-gooders of the internet to build packages for us.
Heard of PPA in the ubuntu world? That's what launchpad does, you can host .deb packages for linux. Not only can you host them, but you can get them built for you. Even on some strange architectures like PPC, and ARM. Pretty damn cool.
You can link up your code to be built by launchpad. Note, you'll need git, and not mecurial (last we tried it didn't work). So, because we are still using mecurial version control (hg) we had to have a git mirror of our hg repo.
https://code.launchpad.net/~pygame/+recipe/pygame-daily
So now we have more than 16 builds happening just for python3. So we have PPA archives people can add to their ubuntu install, and pygame can be updated every time we make a change (which passes tests). Launchpad is a bit rough, but because it's used by Ubuntu I hope it will be around for quite some time.
Of course you need to have debian packaging files setup for your program to be packaged. But if you (or a maintainer) has done that, then it should be quite easy to do. Someone may already have even set up a PPA for their own personal use. So you might have zero work to do.
Another challenge we had is that a 'build badge' doesn't exist. You know the type which tells you if a build is breaking or not? So we had to write a little script which scrapes the build pages for us and creates a little svg file. Another cool thing about launchpad is that it links to the Ubuntu and Debian bug trackers. So you can search in there for any patches and bugs people contribute to those projects. (Often it is far easier for people to submit a patch or bug report to their distro rather than upstream).
Thanks launchpad, and thanks Canonical. You provide a great service to the world. Trillions of industry running on your backs. I owe many {insert_beverage_of_choice} to the people who keep this going.
Our build scripts for appveyor are in the appveyor directory of the pygame repository. We don't build all of the dependencies for windows automatically, since that would take quite some time. Lenard has produced some 'prebuilts', which are downloaded by Appveyor for us (see appveyor/install.ps1).
Thanks very much appveyor, for allowing open source projects to use their build system for free. The windows using world owes you!
We use Travisci for our mac builds and our manylinux builds.
Manylinux is a fairly new thing, which is a binary that will work on many versions of Linux. It does this by not linking to new library symbols in. You can find binary wheels on pypi marked with either
All the travisci related config for building pygame on there is held in .travis* files starting with .travis.yml.
A list of pygame bugtrackers for different distros is kept here: https://www.pygame.org/wiki/patchesandbugs However, this does not show the build status, or allow you to download packages. We don't maintain a list like that (but it's probably something we should do!).
Now, once again people can contribute to pygame without having to set up a dozen build environments. It is Spectacularly Adequate.
Thanks to Lenard Linstrom, Paul Craven, Thomas Kluyver, and others for getting this all up and going. As well as to the people who package pygame for all other platforms.
Continuous integration is great. It's even greater when you have dozens of platforms, and many versions of a python interpreter you need to have things run on. It means your python 2 contributors on linux can see that their change broke an OS X build on python 3. Every change you make things get built for all the different platforms, and tests are run, installers are built, and packages are made.
In 2008 the pygame project had the great fortune for 'thorbrian' and some other contributors to set up a build page for Windows, and Mac. Two platforms which had sort of tricky python build setups not so commonly understood in the FOSS world.
"The Spectacularly Adequate Automated Pygame Build Page" was born. And it was spectacularly adequate. Everyone rejoiced.
 |
| We rejoiced in how spectacularly adequate it was. |
So now people could download builds when we made changes. Then they could test them on their weird windows machine with directx N, and some strange AMD card they found in a rubbish bin somewhere.
Occasionally it would connect to the SVN code repository (yes, it was that old) and it would grab the code and do a build. Awesome. This was some years before things like TravisCI provided free infrastructure to the world (massive shoutout and thankyou the the travis mob).
But at some point a few years later the machines stopped building things. They crashed. Unfortunately no one was able to replace them.
So, a couple of years ago we began the slow process of finding a replacement. There were a few missteps. Of course! Trying to setup our own virtual machines. That worked for a little while. But VMs were changing at such a rate, and no one really had space to host machines that worked all that well. We even started on a project to let anyone upload a build. But this never was finished. We tried to get in contact with a few other python projects, and open source projects but no one was all that interested in replying to emails it seems.
So our project sort of stalled. This wasn't the only reason, but one big one. Without builds being made automatically we went back into the world of things breaking all the time, and waiting for random do-gooders of the internet to build packages for us.
Launchpad - Ubuntu GNU/linux.
Launchpad is a sort of code repository in the sky things for Ubuntu. You can use it for other things, but this is the main thing. It used to be based on the Bazaar version control language, but actually supports other things too.Heard of PPA in the ubuntu world? That's what launchpad does, you can host .deb packages for linux. Not only can you host them, but you can get them built for you. Even on some strange architectures like PPC, and ARM. Pretty damn cool.
You can link up your code to be built by launchpad. Note, you'll need git, and not mecurial (last we tried it didn't work). So, because we are still using mecurial version control (hg) we had to have a git mirror of our hg repo.
https://code.launchpad.net/~pygame/+recipe/pygame-daily
 |
| Look at all the builds! This is just python3. |
Of course you need to have debian packaging files setup for your program to be packaged. But if you (or a maintainer) has done that, then it should be quite easy to do. Someone may already have even set up a PPA for their own personal use. So you might have zero work to do.
Another challenge we had is that a 'build badge' doesn't exist. You know the type which tells you if a build is breaking or not? So we had to write a little script which scrapes the build pages for us and creates a little svg file. Another cool thing about launchpad is that it links to the Ubuntu and Debian bug trackers. So you can search in there for any patches and bugs people contribute to those projects. (Often it is far easier for people to submit a patch or bug report to their distro rather than upstream).
Thanks launchpad, and thanks Canonical. You provide a great service to the world. Trillions of industry running on your backs. I owe many {insert_beverage_of_choice} to the people who keep this going.
Appveyor.
We use Appveyor or its windows build support. It also integrates really nicely with bitbucket, so we don't need to use the github mirror for this one.Our build scripts for appveyor are in the appveyor directory of the pygame repository. We don't build all of the dependencies for windows automatically, since that would take quite some time. Lenard has produced some 'prebuilts', which are downloaded by Appveyor for us (see appveyor/install.ps1).
Thanks very much appveyor, for allowing open source projects to use their build system for free. The windows using world owes you!
Travisci
Travisci works with github, so that when a commit happens the builds are done and the tests are run.We use Travisci for our mac builds and our manylinux builds.
Manylinux is a fairly new thing, which is a binary that will work on many versions of Linux. It does this by not linking to new library symbols in. You can find binary wheels on pypi marked with either
manylinux1_i686 or manylinux1_x86_64.All the travisci related config for building pygame on there is held in .travis* files starting with .travis.yml.
homebrew
Homebrew is a package manager for Macs. It provides build scripts and binary packages so people don't need to build everything themselves from source all the time.
We use these scripts in our builds for the macs. This lets us use the mac build scripts in order that we can try to keep maintenance for these scripts inside homebrew itself.
Thanks very much to the homebrew pygame maintainers!
Other distros.
Other software distributions also build pygame for us. From raspbian, Debian, to Fedora, to homebrew, to exotic rewrites of BeOS . Each of these packagings are done by different people. We try to keep in touch with things going on by looking into their bug trackers from time to time.A list of pygame bugtrackers for different distros is kept here: https://www.pygame.org/wiki/patchesandbugs However, this does not show the build status, or allow you to download packages. We don't maintain a list like that (but it's probably something we should do!).
Bringing it all together?
We put some badges into the readme, so that you can see if things are building or failing the build. You can also go from those links to download binaries. Also the Hacking wiki page is where we keep links to all the build pages and instructions for pygame developers. |
| The build badges in the readme, linking to travisci, launchpad, and appveyor. |
Now, once again people can contribute to pygame without having to set up a dozen build environments. It is Spectacularly Adequate.
Thanks to Lenard Linstrom, Paul Craven, Thomas Kluyver, and others for getting this all up and going. As well as to the people who package pygame for all other platforms.