On 6 August 2015 at 15:04, Nick Coghlan <ncogh...@gmail.com> wrote: > On 6 August 2015 at 09:29, Victor Stinner <victor.stin...@gmail.com> wrote: >> Le 5 août 2015 17:12, "Nick Coghlan" <ncogh...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
