PSF core grant, days 37 & 38: making Python-Dev InI got enough positive feedback on the Python-Dev In a Box idea from my last blog post that I decided to implement it. Over yesterday and today I have been writing some scripts to help bootstrap people into contributing. I will make the code and repository public as soon as I can get the remote repository at hg.python.org created.
So the goal of this project was to make it easy for people to jump in and start contributing at a sprint or on their way home from a conference. That meant providing the code, tools, and information needed to contribute. It also meant doing as much upfront for people as possible so as to not waste time for what everyone would end up doing along with not requiring a network connection. And all of this, at max, needs to fit in 700 MB on a CD.
First, there is a script called make_a_box.py which creates a Python-Dev In a Box instance. It will prompt you for what you want to include in the box:
- CPython (from an Hg repository at the moment, but I might patch it to be from svn if Hg is not ready by PyCon)
- Mercurial and TortoiseHg
- Visual C++ Express (the Web installer)
When reasonable it will build what is provided. In the case of CPython and the various bits of documentation, the docs get built. For coverage.py it runs it so you have a basic coverage report for people to work off of.
For users, I included two extra scripts. One simply builds CPython (on UNIX). While building is very straightfoward (and documented in the devguide), I needed the functionality for generating the coverage report. Since I needed the code anyway I figured I would make it a stand-alone script. About the only real perk to it is that it uses multiprocessing.cpu_count() to run the Makefile with as many cores as you have (although CPython compiles in a fairly linear fashion so extra cores doesn't do that much).
I also provided a script that runs the test suite in the fastest, most rigorous way possible. Once again, while documented in the devguide, people can get a little lazy when it comes to running the entire test suite, so hopefully having a script that uses the "best" options will lead to more rigorous testing overall.
My plan is to create a Box for the PyCon sprints so that people attending the sprint can simply copy from a CD or flash drive everything they need to get going. This should speed up people getting started, leading to more productivity.