Wheelhouse 0.1.3

What is a Wheelhouse?

A wheelhouse is a local cache of python packages in wheel format that gets committed with your code to your VCS. When installing packages during continuous integration and production, the wheels in the wheelhouse are used instead of depending on PyPI or some other network location.

Example Usage

wheelhouse build

vex -mr myproj # or: mktmpenv
wheelhouse install -- -r requirements/dev-env.txt
pip install -e .

Example Project

The code for this project is rather basic, but it’s the concept that counts. Putting the concept of a wheelhouse into practice has made managing dependencies for our projects across dev, testing and production environments much, much easier.

Checkout Keg to see a project which is using a wheelhouse in conjunction with tox to manage dependencies.

Current Features:

• build: Will build all packages for all requirements file specified in the config file and store in the wheelhouse directory. Can also be passed the names of individual packages or aliases.

• config: display the configuration wheelhouse is using.

• purge: purge the wheelhouse of any wheel that isn’t the most recent version in the wheelhouse for that package.

Possible Future Features:

• install: install a package/wheel from the wheelhouse.

• status: compare the working environment’s installed packages with the requirement files, the wheelhouse, and package indexes (PyPI) and show where they are out of sync.

pip Configuration

Once you have a wheelhouse (wheelhouse build), you can tell pip to install only from the wheelhouse. To do that with environment variables and a tox.ini, it would look like:

# tox.ini
[testenv]
setenv =
    PIP_USE_WHEEL=true
    PIP_NO_INDEX=true
    PIP_FIND_LINKS=requirements/wheelhouse

or, from the command line:

pip install --use-wheel --no-index --find-links=requirements/wheelhouse -r requirements/testing.txt

Configuration

You must place a wheelhouse.ini in the base of your project. This is considered the “project root” and all relative file paths are calculated from this location.

You may also place a wheelhouse.ini file in a user-specific location to override defaults for Wheelhouse. See wheelhouse config for more information.

Config files are read by a SafeConfigParser instance. See the linked docs for interpolation support available.

An example configuration file follows:

[wheelhouse]
# These files are relative to the project's requirements directory (default: `requirements/`).
requirement_files =
    build.txt

# Make sure each package has a wheel built for python 2 & 3.
pip_bins = pip, pip3.4

[aliases]
# Shortcuts to be used when specifying projects to `build`.
keg = https://github.com/level12/keg/zipball/master
ke = https://github.com/level12/keg-elements/zipball/master

Issues & Discussion

Please direct questions, comments, bugs, feature requests, etc. to: https://github.com/level12/wheelhouse/issues

Current Status

Very Beta, expect changes.

Development

To develop on this project, begin by running our tests:

git clone https://github.com/level12/wheelhouse wheelhouse-src
cd wheelhouse-src
tox

You can then examine tox.ini for insights into our development process. In particular, we:

• use py.test for testing (and coverage analysis)

• use flake8 for linting

• store pip requirements files in requirements/

• cache wheels in requirements/wheelhouse for faster & more reliable CI builds

Changelog

0.1.3 - 2017-05-30

• BUG: fix bug in handling multiple requirements files