wheel is quite prevalent nowadays. ensurepip even uses wheels of pip & setuptools itself. Installing wheel by default will bestow the following benefits:

1. pip's wheel cache will be enabled by default.
2. Users will be able to run setup.py bdist_wheel. Put simply, they will be able to build wheels.
3. Users will have access to the wheel command by default.

All those benefits will also apply in any created venv (Via the standard venv package). The external virtualenv package already does this https://github.com/pypa/virtualenv/tree/master/virtualenv_support. I often find myself installing wheel manually in any venv I create.

It shouldn't be too difficult to do, but it probably needs some agreement before being done.

Of the listed benefits, I think the most interesting one is the fact it would enable pip's wheel cache by default for all installations, rather than relying on projects publishing pre-built wheel files to PyPI.

However, actually doing this would run counter to the design goal of declaring even the current installation of setuptools to be an implementation details that shouldn't be relied on: https://www.python.org/dev/peps/pep-0453/#automatic-installation-of-setuptools

This relates to the fact that in PyPA, we're aiming to reach a point where we treat setuptools & wheel as *optional* dependencies of pip, such that it's straightforward to create environments that only support installation of wheel files created elsewhere, and don't allow installations directly from source archives at all.

The recently approved PEP 517 represented a notable step in that direction.

That said, we're also discussing the possibility of changing the way we provide distutils to be dependent on automatic installation of setuptools [1], and if we *did* decide to go down that path, then I think it would be appropriate to consider installing both setuptools *and* wheel as part of an "ensuresetuptools" module, rather than just installing setuptools.

Accordingly, while I *am* going to close this (and the related PR), I'm going to close it as "postponed" rather than "rejected" - it isn't that we're definitely never going to do this, it's that there are other long term design considerations involved, and doing this prematurely has the potential to lock us out of design paths that we'd like to keep open.

[1] https://mail.python.org/pipermail/distutils-sig/2017-September/031540.html

As a shorter version of the above:

* the current install time bundling of setuptools in `ensurepip` is likely to be replaced by `pip` dynamically installing both `setuptools` & `wheel` when asked to build from a source archive when no other build system has been specified. With PEP 517 approved, it's entirely plausible that this will happen as part of the `pip 10.0.0` release. So we *won't* be bundling wheel as part of ensurepip, since doing so would conflict with the plan to unbundle setuptools.

* however, we *may* still end up bundling wheel with CPython at some point, *if* we decide to eliminate Lib/distutils entirely in favour of bundling setuptools & wheel.

So it isn't that bundling wheel is entirely out of the question - it's just not something we want to do as part of ensure*pip* specifically.

> * the current install time bundling of setuptools in `ensurepip` is likely to be replaced by `pip` dynamically installing both `setuptools` & `wheel` when asked to build from a source archive when no other build system has been specified. With PEP 517 approved, it's entirely plausible that this will happen as part of the `pip 10.0.0` release. So we *won't* be bundling wheel as part of ensurepip, since doing so would conflict with the plan to unbundle setuptools.

Actually PEP 518 provides the mechanism we need for this, and it's already implemented in pip's master branch (what will become pip 10). I don't remember off the top of my head if that covers 100% of the cases yet, but if it doesn't that's just a SMOP. It's entirely plausible that Python 3.7 ships without setuptools included in ensurepip.