Error message for "Configuring Windows SDK "v7.0" for Python 2 on a 64 bit architecture"

[YannickJadoul]

After printing that Configuring Windows SDK "v7.0" for Python 2 on a 64 bit architecture, there are two red errors in my AppVeyor build:

The system cannot find the path specified.
The system cannot find the path specified.

(cfr. https://ci.appveyor.com/project/YannickJadoul/parselmouth/build/1.0.13/job/4cofnsd0y05jgtb9)

Having had a quick look, it seems as if that's due to the lines

"%WIN_SDK_ROOT%\%WINDOWS_SDK_VERSION%\Setup\WindowsSdkVer.exe" -q -version:%WINDOWS_SDK_VERSION%
"%WIN_SDK_ROOT%\%WINDOWS_SDK_VERSION%\Bin\SetEnv.cmd" /x64 /release

during the execution of https://raw.githubusercontent.com/ogrisel/python-appveyor-demo/09a1c8672e5015a74d8f69d07add6ee803c176ec/appveyor/run_with_env.cmd

This is not urgent, since my build still continues and finishes building everything, I think. But it might be nice to get rid of it (if possible) since the red color dóes make it seems as if there's a problem.

Besides, the python --version call is also highlighted in red, but I'm guessing that's because Python is printing to the stderr. I'll have a look if this is easily resolvable and submit a PR, if I manage?

[YannickJadoul]

(Hold your horses on that python --version, because my latest build is not marking that in red, somehow: https://ci.appveyor.com/project/YannickJadoul/parselmouth/build/job/t0rcu72ygb4weol3)

[joerick]

I don't know what the deal is with Appveyor logs, but they seem to print in the wrong order. Maybe it's related to IO buffering in Python (maybe worth trying an envvar PYTHONUNBUFFERED=1 to see if that fixes the ordering).

Not sure if these messages are benign or not. Let us know what you find!

[YannickJadoul]

I've got an update for you :-)
(https://ci.appveyor.com/project/YannickJadoul/parselmouth/build/1.0.26/job/pyn2gvvuv9ofue48)

• set PYTHONUNBUFFERED=1 && cibuildwheel --output-dir wheelhouse in my .appveyor.yml indeed does the trick for mixing the output of cibuildwheel with that of the called commands. I was already planning to see how to fix this, but it's as simple as that.
  However, do you want to have a more robust solution ín cibuildwheel itself? Calling sys.stdout.flush() after print statements might already do the job? Or maybe there's even a better way. If you want that, I can make that into some kind of pull request?

• python --version presumably still ends up in the stderr, but since I'm using cmd in my latest build, and not PowerShell anymore, it just gets printed and does not end up in red anymore in the output log. I could still fix this (by a small PR that passes stderr=subprocess.STDOUT to the subprocess calls for that python --version call), but personally I am fine with just having it like this, for now (having understood what went on).

• However, the main point of this issue is still there: I still get the messages that The system cannot find the path specified. But I actually don't really know what should happen there. So is it something important? Will my wheels be invalid if that goes wrong?

[joerick]

However, do you want to have a more robust solution ín cibuildwheel itself? Calling sys.stdout.flush() after print statements might already do the job? Or maybe there's even a better way. If you want that, I can make that into some kind of pull request?

A PR for this would be great, if it's possible to do without flush() calls everywhere.

However, the main point of this issue is still there

Yes, indeed. Did you ever find any more info about this?

[YannickJadoul]

A PR for this would be great, if it's possible to do without flush() calls everywhere.

I'll have a look at such a PR. (I've also found out that the output of the compilation gets swallowed somewhere, so I might also include that?)

Yes, indeed. Did you ever find any more info about this?

Not really anything more than what I had there. So this thing seems to happen for Python 2.7 and 3.4 in 64-bit (see here), but not for 32-bit or Python 3.5 and 3.6 (latest build here).

I don't really know what that script is supposed to be doing, however, but I assume you had a good reason for including it? (As far as I know, I have no problems with the wheels that are built, but then I have not really tested them all on different Windows machines...)

[joerick]

This SO answer has the info, but I believe the gist is-

The script sets up a load of environment variables so that the compilation is done using the same compiler that compiled the Python.org distributions of Python. I think. Previously to using this script I was getting errors like these.

[YannickJadoul]

Hmmm, thanks. I'll have a closer look at that tomorrow (even if only to satisfy my curiosity).

Maybe it's got to do with the different VS environments: https://www.appveyor.com/docs/build-environment/ ? I use the latest VS2017 one from AppVeyor, while the documentation states that

If the build configuration does not specify build worker image then Visual Studio 2015 image is used.

That StackOverflow answer also has a lot of updates, so who knows, maybe these things are not needed anymore on a later version?

[joerick]

This page also looks informative - https://github.com/cython/cython/wiki/CythonExtensionsOnWindows

I hadn't thought about the specific appveyor image used - also might be worth comparing with builds done with https://github.com/ogrisel/python-appveyor-demo, since that's where the script came from.

[YannickJadoul]

Still trying to make sense of all of this (and in particular why my builds where these errors occur seem to be working on Windows at all), but these links seem rather interesting, too, so I thought I'd save them in the discussion:

• https://matthew-brett.github.io/pydagogue/python_msvc.html
• http://stevedower.id.au/blog/building-for-python-3-5/ & http://stevedower.id.au/blog/building-for-python-3-5-part-two/