On May 29, 2014, at 9:18 PM, Ben Finney <b...@benfinney.id.au> wrote:
> Barry Warsaw <ba...@debian.org> writes: > >> On May 29, 2014, at 08:15 PM, Scott Kitterman wrote: >> >>> I'd rather [Debian] remove the wheels we have and give up on >>> ensurepip than start down this slippery slope. >> >> That means we give up on pyvenv, and given that virtualenv will >> eventually be a wrapper around pyvenv, that means we give up on >> virtual environments. > > Could you expand on that? What is it about pyvenv, or wheel, or both, > that leads from Debian removing wheel packages to Debian “giving up on > pyvenv”? > > Or, if you prefer, what is it about pyvenv that makes it infeasible to > do without wheel packages? pyvenv doesn't strictly need Wheels themselves, but it needs something that is capable of interrogating Python to ask it where it should install the packages as well as which is capable of understanding virtual environments at all. Historically virtualenv has done this by embedding sdists, manually unpacking them, and then executing setup.py. With the most recent version of virtualenv, and with pyenv (which uses ensurepip) this has been switched to wheels since they are really just fancy zip files which means that Python is able to import them directly. This allows pyenv (again via ensurepip) and virtualenv to use pip to install both itself and setuptools instead of directly executing setup.py. This has made the bootstrapping of setuptools/pip into these virtual environments cleaner, faster, and simpler. Strictly speaking as well, pyvenv itself doesn't require ensurepip (where the wheels are being used). However pyvenv does default to bootstrapping pip into the virtual environment which that particular feature *does* require ensurepip and the Wheel files. In Python 3.3 there is no ensurepip and pyvenv does not include pip, but feedback has overwhelmingly been that 3.3's pyvenv is useless because it does not provide any means of installing things into it like virtualenv does. This has lead people to continue to use virtualenv instead of pyvenv which can hopefully be rectified in 3.4+ now. Additionally it's important to remember that the only reason virtualenv itself works on Debian is because it violates the Debian policy and ships the Wheel files that I (as the person whose released the upstream virtualenv) included within it. The solution that Barry has with pyvenv is more complex than simply including those files as python-virtualenv does, however it is my understanding that is allows pyvenv to be compliant with Debian policy. > >> Wheels are a solution to a problem that is *explicitly* Debian, given >> the policy and DFSG violations vendorizing entails. Upstream doesn't >> have the same concern. > > (I think by “to vendorize” you mean “to bundle”. Why the neologism > “vendorize”, what is the distinction?) I think the general distinction is that bundling is more generic than vendoring. Vendoring typically refers to including the code of another package as part of the code of the primary package. For instance, pip vendors requests (and others) as pip._vendor.requests. It is effectively a part of the pip namespace now instead of simply bundling the two packages together so that installing pip also installs requests. > > What do wheels do which address Debian in particular? Why is it that > Debian can't ignore wheels as superfluous? Wheels don't address a problem that is specific to Debian, as I explained above we need a package to install into the virtual environment. As far as I am aware dpkg is not aware of virtual environments and I cannot install a package (such as python-pip) multiple times into multiple virtual environments on a single machine. So more accurately this solves a generic problem for which the typical Debian machinery does not have a solution for. > > -- > \ “It is well to remember that the entire universe, with one | > `\ trifling exception, is composed of others.” —John Andrew Holmes | > _o__) | > Ben Finney > > > -- > To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/85iooo2hez.fsf...@benfinney.id.au > ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
