The advantage of wheels over eggs is clear (see section why not egg? https://pypi.python.org/pypi/wheel).
However, it is not entirely clear to me what is the advantage of using wheels over tar.gz
. I might be missing something obvious like "they are the same". As I see it both can be installed directly using pip
(even in Windows), have similar size and when packaging require a similar effort. It sounds to me like the kind of questions you might get when justifying a packaging methodology.
EDIT: Just found an example where tar.gz
might be better than wheels. CherryPy (https://pypi.python.org/pypi/CherryPy) provides wheels for Python 3.x only, so if you want to have a local repository to serve CherryPy for Python 2.7 and 3.x dependencies, it seems to make more sense to store the tarball. Is this correct? (just to add a couple of "case-based" justification to the discussion)
If you've installed a Python package using pip , then chances are that a wheel has made the installation faster and more efficient. Wheels are a component of the Python ecosystem that helps to make package installs just work. They allow for faster installations and more stability in the package distribution process.
The way to do this is to download and extract the source distribution ( . tar. gz ) inside a compatible manylinux Docker image (this depends on the architecture you want to target) and then build the wheel with python setup.py bdist_wheel .
Python package installed with pip , e.g. WheelPython dependencies can be specified as dependencies in your packaging, and automatically installed by pip . You can include third party C libraries in wheels, but for sufficiently complex dependencies that won't work.
A built-package format for Python. A wheel is a ZIP-format archive with a specially formatted filename and the . whl extension. It is designed to contain all the files for a PEP 376 compatible install in a way that is very close to the on-disk format.
This answered it for me (directly from the wheel PEP):
Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers.
Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment.
https://www.python.org/dev/peps/pep-0427/#rationale
Note the tarballs we're speaking of are what are referred to as "sdists" above.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With