On 6 August 2015 at 15:04, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 6 August 2015 at 09:29, Victor Stinner <victor.stinner@gmail.com> wrote:
Le 5 août 2015 17:12, "Nick Coghlan" <ncoghlan@gmail.com> a écrit :
A hard dependency on wheel wouldn't fit into the same category - when folks are using a build pipeline to minimise the installation footprint on production systems, the wheel package itself has no business being installed anywhere other than developer systems and build servers.
I'm quite sure that virtualenv is used to deploy python on production.
Pip 7 automatically creates wheel packages when no build wheel package is available on PyPI. Examples numpy and any pure python package only providing a tarball.
For me it makes sense to embed wheel in ensurepip and to install wheel on production systems (to install pacakes, not to build them).
pip can install from wheels just fine without the wheel package being present - that's how ensurepip already works.
pip can also do this without setuptools being installed; yet we bundle setuptools with pip in ensurepip. I am thus confused :). When I consider the harm to a production pipeline that using setuptools can cause (in that it triggers easy_install, and easy_install has AFAIK none of the security improvements pip has added over the last couple years....), I find the acceptance of setuptools, but non-acceptance of wheel flummoxing.
The wheel package itself is only needed in order to support the setuptools "bdist_wheel" command, which then allows pip to implicitly cache wheel files when installing from an sdist.
Installing from sdist in production is a *fundamentally bad idea*, because it means you have to have a build toolchain on your production servers. One of the benefits of the wheel format and projects like devpi is that it makes it easier to discourage people from doing that. Even without getting into Linux containers and tools like pyp2rpm, it's also possible to create an entire virtualenv on a build server, bundle that up as an RPM or DEB file, and use the system package manager to do the production deployment.
Yes: but the logic chain from 'its a bad idea' to 'we don't include wheel but we do include setuptools' is the bit I'm having a hard time with.
However, production Linux servers aren't the only case we need to care about, and there's a strong user experience argument to be made for providing wheel by default upstream, and telling downstream redistributors that care about the distinction to do the necessary disentangling to make it easy to have "build dependency free" production images.
We've learned from experience that things go far more smoothly if we thrash out those kinds of platform dependent behavioural differences *before* we inflict them on end users, rather than having downstream redistributors tackle foreseeable problems independently of both each other and upstream :)
Hence my request for a PEP - I can see why adding wheel to the ensurepip bundle would be a good idea for upstream, but I can also see why it's a near certainty downstream Linux distros (including Fedora) would take it out again in at least some situations to better meet the
Does Fedora also take out setuptools? If not, why not?
needs of *our* user base. (Since RPM has weak dependency support now, we'd likely make python-wheel a "Recommends:" dependency, rather than a "Requires:" dependency - still installed by default, but easy to omit if not wanted or needed)
So, a new PEP? -Rob -- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Converged Cloud