Date: Thu, 25 Jun 2015 23:59:15 -0400
From: Randy Syring <randy@thesyrings.us>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: python-announce-list@python.org, distutils sig <distutils-sig@python.org>
Subject: Introducing Wheelhouse
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Approved: python-announce-list@python.org
Newsgroups: comp.lang.python.announce
Message-ID: <mailman.101.1435302512.3674.python-announce-list@python.org>
Lines: 58
NNTP-Posting-Host: 2001:888:2000:d::a6
Path: csiph.com!usenet.pasdenom.info!news.stben.net!border1.nntp.ams1.giganews.com!nntp.giganews.com!bcyclone03.am1.xlned.com!bcyclone03.am1.xlned.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Xref: csiph.com comp.lang.python.announce:1755

Wheelhouse is a utility to help maintain a wheelhouse.

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 <https://github.com/level12/keg> to see a project which is 
using a wheelhouse in conjunction with tox to manage dependencies.


    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.


      Advantages:

  * Wheels are stored in your DVCS bringing further clarity to exactly
    what packages are needed/expected and how they have changed over time.
  * CI builds are faster and more consistent. Due to the increased speed
    of installing wheels from a local cache instead of pulling them from
    a network location, we can have tox start with a new virtualenv
    before every run, thereby insuring all dependencies have been
    specified and installed into the wheelhouse correctly.
  * Production deployments are similarly fast and consistent. Since the
    CI and production servers both pull from the same wheelhouse we have
    higher certainty that our production code is running against the
    exact same packages that have been tested.
  * Since wheels are built on development or build machines, the need
    for development system packages to be installed on production
    servers is removed.
  * Targeting forks, development versions, unpublished, and/or private
    software for production is much easier than setting up & maintaining
    a private PyPI server like devpi <http://doc.devpi.net/latest/>.
  * Splits the package management process into two distinct steps:
     1. Build packages (from various locations, with specified version)
        and put wheels in the wheelhouse.
     2. Install the latest version of a package from the wheelhouse.


      Links:

https://pypi.python.org/pypi/Wheelhouse
https://github.com/level12/wheelhouse


*Randy Syring*
Husband | Father | Redeemed Sinner

/"For what does it profit a man to gain the whole world
and forfeit his soul?" (Mark 8:36 ESV)/