Introducing Wheelhouse
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)/
Thanks! .wheelhouse.ini! /requirements/wheelhouse/<cachedbuiltwheels> On Thu, Jun 25, 2015 at 10:59 PM, Randy Syring <randy@thesyrings.us> wrote:
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)*
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
*wheelhouse.ini On Fri, Jun 26, 2015 at 1:14 AM, Wes Turner <wes.turner@gmail.com> wrote:
Thanks! .wheelhouse.ini! /requirements/wheelhouse/<cachedbuiltwheels>
On Thu, Jun 25, 2015 at 10:59 PM, Randy Syring <randy@thesyrings.us> wrote:
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)*
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
participants (2)
-
Randy Syring -
Wes Turner