So I think that the debundling of requests, html5lib, etc that python- pip does and rewheel are mutually incompatible and are going to lead to a lot of end user pain.
Specifically the reason we bundle those things in pip is because if pip depends on requests, and someone does ``pip install requests==1.0`` then their pip will break and they'll have to manually uninstall requests and manually install the correct version of requests. Specifically this policy in pip of bundling instead of depending on has come from our experience with our current single dependency (setuptools) and the pain that people have had release after release where things would just completely break unless they were very careful to do things in a particular order. I suspect that problem would get even worse with a dependency that other people actually depend on and not something that most people just happen to have installed alongside their own dependencies. I think supporting the ability to arbitrarily install different versions of things, even if pip itself depends on it, is important because that's one of the primary use cases for a virtual environment. You *could* theortically make it work by making rewheel rebundle those things inside of pip, but you'd also need to undo the patch Debian does to the import statements (although likely pip would just be smarter about those instead) but the real killer there is that pip has modified the import statments in some of those bundled modules in order to have them import other bundled things instead of globally installed things. In general I think the decision has to be between: 1) Treat the .whl files in ensurepip as data files, or alernatively bundled copies of code that are intended to be bundled (as per the Debian manual in 4.13), and continue to do your normal modifications to python-pip. 2) Don't debundle things from python-pip (thus making you have to maintain a second set of patches against anything bundled) and rewheel into the venv. 3) Leave ensurepip broken and make myself and lots of Python developers sad ;( In general my preferences are 1, 2 and a very very very very far in the back 3. Additionally 1 matches with how python-virtualenv is treated (which has copies of pip/setuptools in exactly the same way as ensurepip) in that they are moved to /usr/share instead of being kept inside of the package directory. One *possible* solution is to install the bundled things into their own private directory and modify sys.path inside of pip to import from there, but I think that is going to cause a lot of bugs and broken behavior because pip looks at sys.path to figure out what is installed and it will probably see requests is installed and try to uninstall it to install an upgraded version, or not install requests into the virtual environment where others can access it because it sees requests installed on it's sys.path. There's also a relatively minor UX concern if 2) is the solution that issuing a ``pip install --upgrade pip`` in a virtual environment will get you an unmodified copy of pip so you'll end up with a slight set of subtle differences, the most obvious being what CAs are trusted. However some of that will hopefully be mitigated in the future by pip trying to use the system CA certs and falling back to our own. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1290847 Title: pyvenv fails due to mising ensurepip module To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1290847/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
