New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
distutils cannot find Build Tools 2017 since 3.7.2 #79880
Comments
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 see microsoft/vswhere#125 for more details. The solution is to add
to the vswhere.exe call. This is a regression of https://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. |
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/issue35795 According 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 |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: