On May 29, 2014, at 9:18 PM, Ben Finney wrote:
> Barry Warsaw 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
