Curtis: by design, ``ensurepip`` isn't permitted to assume internet access (since we want both it and venv to work without warnings or errors on systems with no internet access). This was covered in the original PEP: https://www.python.org/dev/peps/pep-0453/#implementation-strategy

The default presence of `setuptools` and `wheel` in `venv` created virtual environments at all is also an implementation detail that's likely to change once PEP 517 is implemented (again, as per the original design in PEP 453).

Emily: for 3.5+, venv is recommended just because it avoids the extra 3rd party dependency, and integrates slightly more nicely with the interpreter internals. As soon as you need greater assurances of cross-version consistency though, virtualenv is the better choice. (Donald Stufft actually has a virtualenv refactoring pending that makes it just a thin shell around venv on 3.5+, but pursuing that's on hold for now due to other priorities)

For the auto-upgrade aspect, environment managers like `pew` offer more flexibility to automate that kind of thing in a way that's consistent across Python versions. It *might* make sense to offer a `--upgrade-pip` flag for `venv` creation, but it's not entirely clear how much benefit that really offers over just running `python -m pip install --upgrade pip` inside the venv yourself. That one's probably worth filing as a separate RFE though, as it's probably the single most common post-creation script for new virtual environments.