vshwere.exe doesn't return Build Tools 2017 per default. This means Build Tools 2017 are not detected by distutils in 3.7.2 and you get the famous "Microsoft Visual C++ 14.0 is required" error.Please seehttps://github.com/Microsoft/vswhere/issues/125 for more details.The solution is to add     "-products", "*",to the vswhere.exe call.This is a regression ofhttps://bugs.python.org/issue35067.

Excellent catch! Are you interested in creating a PR?Also, I don't recall whether we are handling multiple installs or not, but if we are not I would rather explicitly list the products that may include compilers than using "*" (since there are and will be more products that do not). If we're checking for installed packages as well and iterating over all results then "*" will be fine.

We are passing arguments -latest        (Return only the newest version and last installed.)and "-requires", "Microsoft.VisualStudio.Component.VC.Tools.x86.x64",So this should handle the cases multiple installs and different products without compilers.I try to get a PR ready.

Reminder to myself (or permission for anyone else) to merge this. My phone won't let me actually click the github merge button, unfortunately, but this seems good to go.

New changesetb2dc4a3313c236fedbd6df664722cd47f3d91a72 by Ned Deily (Marc Schlaich) in branch 'master':bpo-35699: fix distuils cannot detect Build Tools 2017 anymore (GH-11495)https://github.com/python/cpython/commit/b2dc4a3313c236fedbd6df664722cd47f3d91a72

New changeset2fa53cfa8960f4bcb36718da4424e980fc305ef5 by Miss Islington (bot) in branch '3.7':bpo-35699: fix distuils cannot detect Build Tools 2017 anymore (GH-11495)https://github.com/python/cpython/commit/2fa53cfa8960f4bcb36718da4424e980fc305ef5

Merged on behalf of Steve.  Thanks, Marc!

There is one buildbot (https://buildbot.python.org/all/#builders/40/builds/1524) that started randomly failing unrelated tests with this change - usually one of zipapp, pkgutil, or zipimport. I don't have any idea what the relationship here is, unless the distutils tests have stopped skipping on those machines and are affecting some sort of global state (which they shouldn't, and the other tests shouldn't be relying on, but here we are).I haven't looked at the actual tests (from my phone) yet. Anyone have any better ideas?

I read a few of the logs, and all errors roots in the same place, when the test case tries to remove the tempdir during teardown/cleanup. The Windows (and other platforms not supporting directory fds) implementation of rmtree can have race conditions if files are added while the directory being walked, causing the error.I don’t know the case of CPython, but Pipenv has a similar problem when running concurrent tests with subprocesses. We never solved it (but simply wrap the rmtree call inside a try block and look away).

@Steve, we are investigating and tracking this issue here:https://bugs.python.org/issue35795According to the buildbot owner "directory tree removal needs to go through support.rmtree, not any of the stdlib methods for doing so.  In a nutshell, the tests need to be changed to do this".Not sure why this has happened now