Old virtstrap-core repository. PLEASE DO NOT USE. It is only around for historical reasons. Checkout the current project at https://github.com/ravenac95/virtstrap
Python Shell
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.



A simple script that allows you to setup a repeatable project using a variety of tools. The project came out of a need to use some things from buildout and some things from pip and virtualenv. However, eventually buildout support was abandoned as pip and virtualenv were powerful enough for the job.

Main Goals

  • Create repeatable projects between other developers and environments
  • Provide a simple and easy to use interface
  • Create Gemfile/Gemfile.lock like system
  • Set custom environment variables in the virtualenv
  • Setup multi python virtualenvs
  • Create a plugin system similar to buildout with more flexibility
  • Allow for local repository of compiled python modules so new virtstrap environments don't continually go online to find a module.
  • A configuration file that is portable to more than just virtstrap. This allows for programs that aren't virtstrap to take advantage of the the configuration file.

Why I made virtstrap

Essentially, there was a short period of time where I was a little obsessed with using zc.buildout. However, I quickly found out that if I needed to quickly experiment a library it was not as simple as installing it through pip. In addition, I found buildout's support for a --no-site-packages like function to be unsatisfactory. One package on my Mac, ipython, was particularly finicky when using buildout. For those of you who have not experienced it, ipython does not work well with Leopard's version of libedit. However, installing readline via easy_install is the only way to get it to work (oddly enough it won't work through a pip installation). So this forced me to come up with a solution that would solve my problems of repeatability and flexibility.

The result is virtstrap.

Is this yet another build tool?

Yes and no. Virtstrap is meant as a layer above virtualenv+pip to give the user buildout like capabilities without all the buildout overhead (i hope).

Why not virtualenv-wrapper?

I looked into using it but it did not fit my particular needs. It's a great tool but I originally wanted to create a tool that didn't have to be installed system wide to see use. Now, however, I see that as a horrible oversight and an unnecessary limitation. Although I still feel there is something elegant about keeping the package out of the global system, it now seems unreasonable to me. As a consequence, this question seems even more relevant. However, after having built the initial versions of virtstrap, I realized that virtstrap could make virtualenv-wrapper even simpler. It could also be shared between developers, build systems, and any number of scenarios. So, here's my crack at making something truly useful for python development.

virtstrap Quick Start Guide

The easiest way to get started with virtstrap is to install it on your local machine by simply doing the following:

pip install virtstrap

Note: If you don't want to install it into your system. Look below for an alternative installation.

To add virtstrap to your project. The most basic usage is:

cd path_to_your_project_path
vstrap init

This will add a directory named .vs.env and a file called quickactivate.sh to your directory.

Configuration Files

As of 0.3.x configuration files won't be required. Granted, virtstrap isn't very useful without it, but, if you really want to start a virtstrapped environment without doing anything, it's as simple as vstrap init.

To get more out of virtstrap you should define a VEfile. This stands for virtual environment file. This is a general purpose file to be used for defining your virtual environment.

The configuration file will be expected in one of the following locations inside your project's root directory.

  • VEfile
  • conf/VEfile

At the moment the file is a YAML file. Eventually I hope to move away from yaml as its syntax can get in the way of defining requirements and the general environment.