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:
- 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 setup.py file
- Activate the virtual environment in the usual way:
- 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.