Could this be relaxed for Travis + newer VS?

[henryiii]

I think this removal could be disabled if DISTUTILS_USE_SDK=1 and MSSdk=1 are set.

https://github.com/joerick/cibuildwheel/blob/ecbdc2e3d37e726e4cd0d0fd5ca1c3d53ebcedaf/cibuildwheel/windows.py#L63-L66

This would enable Travis to build all possible combinations for C++11+ projects.

[YannickJadoul]

Good catch! I'd forgotten about this, indeed, when testing and documenting the workaround.

I'd actually maybe argue to just remove this check always, and not just when DISTUTILS_USE_SDK and MSSdk are set. It might now be unexpected that 2.7 isn't build on Travis CI Windows runs, and we could add a note saying to add CIBW_SKIP=cp27-* if necessary?

On the other hand, the philosophy of cibuildwheel has been to work with minimal configuration and take away worries from the user, so maybe it's not the best idea to have the default configuration error on Travis CI? :-/
Also, in general: if you ask me, the workaround for Python 2.7 on Windows should still stay the hackish workaround (which comes with implications about compatibility) it is. So maybe that suggests @Henriii's suggestion is the best one.

[henryiii]

I agree, I don't think we should automate the workaround (though built-in support via an explicit option would not be turned down!); as it adds the SDK redistributable requirement and also requires that your C++ code be a "good citizen" (such as PyBind11).

I only have 1-2 libraries where "works absolutely everywhere" is important; and I'm hoping that they will drop 2.7 once they hit 1.0 status, so I don't think it justifies any extra work in making a special option just for this case.

PS: I'm actually surprised that I didn't need the same sort of workaround for Python 3.5 on Windows, as that compiler is also old enough to not support the C++14 that Boost.Histogram needed. The pyproject.toml part of build didn't work on 3.5 + Windows for some reason, but it did build, which I did not expect (just missed setuptools_scm). Maybe it could be a general setting in the future to select a different Windows toolchain (ideally per Python version?)?

[YannickJadoul]

I agree, I don't think we should automate the workaround (though built-in support via an explicit option would not be turned down!); as it adds the SDK redistributable requirement and also requires that your C++ code be a "good citizen" (such as PyBind11).

Exactly! Not sure how clear this is from the docs, actually. You think that's OK?

I only have 1-2 libraries where "works absolutely everywhere" is important; and I'm hoping that they will drop 2.7 once they hit 1.0 status, so I don't think it justifies any extra work in making a special option just for this case.

Yeah, it would be nice, but already writing the tests was very painful. Guess it would be possible, but at the same time, I also hope that Python 2.7 is almost dead and we can forget about this :-)

PS: I'm actually surprised that I didn't need the same sort of workaround for Python 3.5 on Windows, as that compiler is also old enough to not support the C++14 that Boost.Histogram needed. The pyproject.toml part of build didn't work on 3.5 + Windows for some reason, but it did build, which I did not expect (just missed setuptools_scm). Maybe it could be a general setting in the future to select a different Windows toolchain (ideally per Python version?)?

Yes, it also took me a while to figure out, but while Python 3.5 was built with VS 2015 (I think?), it's still MSVC 14.something (https://wiki.python.org/moin/WindowsCompilers). And ever since then, MSVC and the redistributables have been backwards compatible, I believe! Not entirely sure, but... it works :-) (see https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads and https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering). Python 3.4 would need a similar workaround, but is not supported anymore, anyway.

[henryiii]

This was fixed in 1.8.0, in #545.