Using SublimeText2 with VirtualEnv

I recently switched from using Eclipse as my main Python development environment to SublimeText2. The main reason to switch was that Sublime seems to work better on smaller screens: I figured that a little investment in learning this package might make me more productive when I work on my laptop.

The problem with Sublime is that when first installed it does not do a whole lot other than edit text. You need to configure your project or build-settings before it can actually launch code you’ve written. And while it does come with some pre-set ‘Build Systems’ (that’s Sublime’s jargon for a run-configuration), none of them are ideally suitable for Python development with VirtualEnv.

After a great deal of trial and error I’ve come across a formula for setting things up which seems to work rather well. First of all, you need to set up each of your workspaces in a standardized way.

  • Begin by making a new virtualenv – use whatever configuration you like, for example:

virtualenv myproject

  • Next checkout whatever code you want to work on into the /src folder of your new virtualenv dir. This folder should be the location of your file
  • Activate the virtual environment in the usual way:

source myproject/bin/activate

  • Build your project, install any test-dependencies¬†and verify that everything works from the command-prompt.

Now that your basic environment is provisioned, all you need to do is provide a sublime-project file. Here is one I made earlier. Save that file into your main project folder (not the /src folder). You might have to edit some of the paths to point to the actual locations of your tests. Since all my projects use the same configuration layout I can recycle most of this configuration from one project to another. The only things I ever need to change are the locations of specific things in my projects.

The important section to take note of is build_systems – these are the various configurations for how to run my project. You will notice that I don’t actually use the activate or deactivate commands. Rather than modify the environment it turned out to be a great deal easier just to ensure that everything is invoked using the virtualenv’s copy of Python rather than the system version.

Yo Dawg, I heard you like Jenkins

These past few days I’ve been busy re-factoring my JenkinsAPI project. One of my goals was to greatly increase test-coverage. It’s somewhat ironic that a project that was all about testing had very few tests.

Most of the tests in this package try to do something to a Jenkins server and then check for consistency:

For example you can start with a new, clear Jenkins. If you add a new Jenkins job and then read-back the list of jobs you might expect to see one more job in that list. This sort of test is easy to get working on a PC, you simply start up Jenkins before running the tests. But what of the situation where these tests are run on a remote CI server, for example on Jenkins. Any tests that connect back to the server and mess about with that server’s configuration are bound not to work reliably.

I heard you like Jenkins

In order to get this kind of test working in a Jenkins environment the solution I found was to launch another Jenkins.

I wrote a threaded Jenkins launcher which starts a background sub-process and then monitors the Stdout and Stderr streams for error conditions. It returns, keeping the sub-process alive once the Jenkins server has fully started. We keep a reference to the subprocess so that when all the tests are complete I can shut the whole thing down.