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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s