Hello.

First of all, thank you for your work. New virtualenv looks very good and its codebase is clean and readable 👍 Second thing is that I don't want to start another discussion about bundled wheels and their support and updates. I just have a problem to solve and I'd like to do it in cooperation with you because I think that it might help other maintainers.

We'd like to update the python-virtualenv RPM package in Fedora from version 16.7.10 to 20.0.20. The problem we have to solve is that we want the virtualenv provided by the distribution to use our own wheels for pip/setuptools/wheel.

When searching for wheels, we first need to take a look into ensurepip folder like /usr/lib64/python3.4/ensurepip/_bundled — this folder exists only for some Pythons like 3.4 or 2.7 and the path is obtained from ensurepip module import ensurepip; print(ensurepip.__path__[0]). If we don't find a proper wheel there, we take a look into /usr/share/python-wheels where we always find a wheel for all three bundled packages. The latter might contain wheels not compatible with an older Python so ensurepip always has to take precedence.

We always solve this problem by a downstream patch but you can probably imagine that it's not an easy task to maintain a patch like this. So, I'd like to discuss our solutions with you and we might find a better way which makes it easier for us to use the latest virtualenv with our own wheels.

The main problem with the biggest impact on how the patches mentioned below look is that we always need to have a path to Python interpreter we create a virtual environment for to be able to get the ensurepip path mentioned above.

In solution 1, I've implemented a module with a simple function that yields paths to bundled wheels. I then use it in BaseEmbed to alter extra_search_dir and in pip_wheel_env_run for the same purpose. The patch is here: https://github.com/frenzymadness/virtualenv/pull/1/files

Then I have had an idea to implement it in a different way. I've implemented BUNDLE_SUPPORT as an object which gives me a correct path for each wheel. This looked promising but then, because it also needs to have a path to Python interpreter, it gets complicated. I had to change a lot of functions going down to get_bundled_wheel to pass creator or interpreter to it. The patch is here https://github.com/frenzymadness/virtualenv/pull/2/files

The important thing is that we cannot save the paths somewhere because the wheels are generated by other packages and they might be updated without python-virtualenv update.

What do you think about it? Might it be possible to provide an alternative mechanism (some kind of plug-in) to determine the correct path to bundled wheels?

I am not asking you to implement it for us but you might see something I don't and if we will find a good solution that makes it possible to extend virtualenv this way, I'll be glad to implement it.