On Feb 25, 2015, at 05:40 PM, Scott Kitterman wrote: >I'm confused. Having re-read the bug, I don't see how this is anything other >than user error in Debian. As I read it, your proposed solution is directly >contradictory to what we wrote about .whil files in our Python policy: > > A very limited set of wheel packages are available in the archive, > but these support the narrow purpose of providing the Python 3 > built-in virtual environment creation executable > pyvenv-3.X, as well as the within-venv pip > executable, in a Debian policy compliant way. The set of packages > providing wheels for this purpose are (by source package name): > chardet, distlib, html5lib, python-colorama, python-pip, > python-setuptools, python-urllib3, requests, and six. > >I don't see anywhere where use of the .whl packages was envisioned outside >the venv. > >If there is a bug here, I don't think using .whls at the system level >(outside of venv) is the right answer. I think it's just that I had an incomplete understanding of the issue. Specifically, I was overlooking the use of `pip --user` outside a venv, mostly because I've never really used it. I see `pip --user` as a similar use case to pip-inside-venv in that this isn't about touching the system in any way but in creating a Python development environment for whatever the user is trying to personally do. It means the exact same issue comes up for someone using pip-inside-venv and pip --user. pip *itself* must have a known working set of its dependencies and it really doesn't matter whether that's inside a venv or outside with --user. What we absolutely do not want to support - and I think there's universal agreement on this - is people using pip to modify their global system Python state. If this was about sudo pip installing a newer requests into system Python, I'd call pebkac and won't fix it. I don't think the pip --user case substantially changes Python policy, although the existing wording is inaccurate. I'm happy to fix that, but it will have no practical effect on our use of wheels, and will not open any additional doors to drive a multi-wheeled truck through. (It needs updating anyway because this isn't specifically about Python 3, since virtualenv had exactly the same policy violations that caused us to use wheels in the first place for pyvenv. We just didn't realize it at the time, and we fixed that in exactly the same way.) Cheers, -Barry
Attachment:
pgpl80CTeH0Lj.pgp
Description: OpenPGP digital signature