Re: Proposed changes to python-virtualenv
On May 29, 2014 8:27:07 PM EDT, Donald Stufft <donald@stufft.io> wrote:
>
>On May 29, 2014, at 8:15 PM, Scott Kitterman <debian@kitterman.com>
>wrote:
>
>> On May 29, 2014 7:54:53 PM EDT, Barry Warsaw <barry@debian.org>
>wrote:
>>> I'm looking again at updating tox to the latest upstream 1.7.1.
>Along
>>> the
>>> way, I'd like to make /usr/bin/tox a Python 3 script.
>>>
>>> This requires that virtualenv be importable, e.g. `$python -m
>>> virtualenv`. It
>>> is today in Python 2 since /usr/bin/virtualenv is a Python 2 script
>and
>>> we
>>> only build it for one version of Python. I want to change that too,
>so
>>> that
>>> at least we build the virtualenv modules for both Python 2 and 3.
>I'd
>>> like to
>>> switch /usr/bin/virtualenv to be Python 3 as well, and I'd like to
>>> tackle the
>>> vendorizing issue similar to how we fixed it with ensurepip, since
>we
>>> have all
>>> the wheels we need now.
>> ...
>>> Thoughts?
>>> -Barry
>>
>> I'd rather remove the wheels we have and give up on ensurepip than
>start down this slippery slope.
>>
>> Wheels are an ugly solution for us to work around upstream doing
>things that can most charitably be described as fixing problems we
>don't have. No more.
>>
>> Scott K
>
>Eh, it’s not true that users of Debian do not have the problems that
>ensurepip
>solves. Perhaps *you* don’t personally have them but anyone whose ever
>needed
>to install a set of Python packages that Debian either doesn’t package,
>or
>packages the wrong version of them have the problems that
>virtualenv/venv
>solves and virtualenv/venv without pip is practically worthless.
I was referring to wheels. It's my understanding that they are primarily for platforms without package management.
Scott K
Reply to: