Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA. This is necessary for legal reasons before we can look at your contribution. Please follow these steps to help rectify the issue:

1. If you don't have an account on b.p.o, please create one
2. Make sure your GitHub username is listed in "Your Details" at b.p.o
3. If you have not already done so, please sign the PSF contributor agreement
4. If you just signed the CLA, please wait at least a day and then check "Your Details" on bugs.python.org to see if your account has been marked as having signed the CLA (the delay is due to a person having to manually check your signed CLA)
5. Reply here saying you have completed the above steps

Thanks again to your contribution and we look forward to looking at it!

Relevant issue: https://bugs.python.org/issue29523

Added also my github username to bpo, hopefully the bot will update the CLA label.

Also I think this change should be made as well for the 3.6 branch (maybe 3.5 as well?).

Codecov Report

Merging #67 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #67      +/-   ##
==========================================
+ Coverage   82.37%   82.37%   +<.01%     
==========================================
  Files        1427     1427              
  Lines      350948   350952       +4     
==========================================
+ Hits       289091   289095       +4     
  Misses      61857    61857

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 649a7ca...2933a5e. Read the comment docs.

I'm also reluctant to do this. It seems too likely that people will start to assume that the unbundled dependencies (six, appdirs, ...) are shipped with Python, and not specify their own dependencies correctly.

@dstufft Your point is quite reasonable from the upstream point of view.

As a downstream packager where setuptools is being unbundled and the system one is being used (thus updating it now means breakage due to missing wheels as is now), I'll have to follow this approach until PEP 518 is implemented.

Anyway feel free to close it if you disagree with the changes, I'll have to carry the patch downstream to fix the current Fedora issues but it can be removed later on.

I don't see any reason not to accept this contrib. It helps align with the current known state of affairs. When PEP 518 lands, this code can be readily replaced with the PEP 518 solution and until then, ensurepip isn't blocked from working with the latest setuptools versions. I don't think anyone here sees this change as a precedent or reason not to adopt PEP 518.

people will start to assume that the unbundled dependencies (six, appdirs, ...) are shipped with Python

I really doubt it. First off, you have to ensurepip, so it doesn't come with Python by default. But more importantly, most users currently upgrade pip and setuptools to install packages, so will end up with these packages installed anyway in virtualenvs and system envs. So if the presence of these packages is going to lead to incomplete dependency declarations, that risk is already present. Even so, these issues will shake out in short order when setuptools and pkg_resources aren't a standard dependency.

I'm against this PR too. In chatting with people at PyCon, many were shocked that setuptools is not guaranteed to be installed by default (mostly on Windows/Mac) and might be removed in the future, and if we add more packages then it will cause further angst when/if we remove those.

Though since PEP 518 has been merged, presumably the next release of pip will be good to embed without setuptools?

Setuptools is bundling its dependencies again [0] as of version 36.0.0. Closing this PR.

[0] pypa/setuptools#980 (comment)