Latest appveyor build platform update introduced a python problem?

mattwcraig's Avatar


23 Jul, 2015 03:35 AM

I noticed today that a build for an open source project was failing in a way it hadn't a few days ago. The problem is that when I try to run a python script python doesn't appear to be starting.

I played around this evening and have a pair of builds in which the only change is the appveyor platform (the os setting) that demonstrates the problem.

A successful build, with os: Previous Windows Server 2012 R2, is at

A build that looks successful, but actually isn't, is at

Note that in this second link there is much less output of the command at the line I've linked to.

The only change between the runs is a single commit that added the os line.

Unfortunately, I seem to be seeing something similar locally too -- I would swear this script ran locally about a week ago before installing a bunch of Windows updates and now it doesn't.

Any insight would be appreciated.

Matt Craig

  1. Support Staff 1 Posted by Feodor Fitsner on 23 Jul, 2015 03:49 AM

    Feodor Fitsner's Avatar

    Hi Matt,

    What was the last successful (or "correct") build?

  2. 2 Posted by mattwcraig on 23 Jul, 2015 03:59 AM

    mattwcraig's Avatar

    Hi Feodor,

    Looks like the last successful run that tested this line of the script was:

  3. Support Staff 3 Posted by Feodor Fitsner on 23 Jul, 2015 04:12 AM

    Feodor Fitsner's Avatar

    So, that build #48 was on July 18th and the next one #49 on July 19th failed.

    That's the puzzle - the last image update was on July 21st and previous one was on July 13th. There were no updates between that time.

    Could it be some external dependency that changed?

  4. 4 Posted by mattwcraig on 23 Jul, 2015 04:37 AM

    mattwcraig's Avatar

    I thought that might be the case too, but the two builds linked to in the original message were both run tonight, about 30 minutes apart, and the only change in the source was changing the os. I just took a quick look at three logs and it looks like none of the dependencies changed in that time.

    There differences in dependencies that were released yesterday and today, but the ribs tonight seem to exclude that change as the cause.

    #49 is actually OK -- in that case there were no recipes, so the python script in the if statement never gets run.


    Sent from Mailbox

  5. Support Staff 5 Posted by Feodor Fitsner on 23 Jul, 2015 04:43 AM

    Feodor Fitsner's Avatar

    If #49 is OK then when the build started failing exactly?

    Do you have any idea what may be missing/broken on a build server as there is no error like "The library X is missing" or something. Is there any way to get more descriptive error?

    It's really important to understand whether it's environment or external dependency.

  6. 6 Posted by mattwcraig on 23 Jul, 2015 04:47 AM

    mattwcraig's Avatar

    I'll take a closer look in the morning. I've got a local websites box I can give it a try on top, perhaps that will help shed some light.

    Sent from Mailbox

  7. Support Staff 7 Posted by Feodor Fitsner on 23 Jul, 2015 04:48 AM

    Feodor Fitsner's Avatar

    Yes, sure. Thanks!

  8. 8 Posted by mattwcraig on 23 Jul, 2015 02:42 PM

    mattwcraig's Avatar

    So I think it is related to the build server configuration, but I still don't have a more detailed error message.

    First, results of some new runs, all with version numbers of the external dependences pinned to the same value:

    • #78: Runs on whatever the default hardware config is for this repo, does NOT run script as it should.
    • #79: os explicitly set to Windows Server 2012 R2. Behavior is the same as in #78, script is not run.
    • #80: os is set to Previous Windows Server 2012 R2. Script runs.

    To be clear, the only difference on my end between these three builds is whether os is set or what value it is set to.

    To muddy the waters a bit further, it isn't clear to me why this script ever ran the way I'm launching it because it looks, based on the file type association for .py files, like it would always have been launching the the appveyor-installed python...though my knowledge of Windows file type associations and paths is rudimentary enough that I could be completely wrong about that.

    So, to summarize: it looks like something in the build configuration changed. I have no idea how to dig up more details about what or why.

    I do have a workaround I can use, so I'll leave it up to you whether we continue trying to pursue this (I'm happy to if you want).

  9. Support Staff 9 Posted by Feodor Fitsner on 23 Jul, 2015 03:25 PM

    Feodor Fitsner's Avatar

    So, the issue is in ".py" file association that doesn't work anymore?

    - Feodor

  10. 10 Posted by mattwcraig on 23 Jul, 2015 03:56 PM

    mattwcraig's Avatar

    That is how it appears to be acting, but the output of assoc .py is Python.File in all three of the runs, and ftype Python.File is the same in all three.

    I'm going to add a few more statements to appveyor.yml try to debug this a little further, and maybe simplify the context in which it occurs.

  11. 11 Posted by mattwcraig on 23 Jul, 2015 06:42 PM

    mattwcraig's Avatar

    Hi Feodor,

    I have this down to a much more minimal example that illustrates the change. There are no external dependencies and the repo consists of two files, appveyor.yml and The second is a three line script whose expected output is something Hello world! and a line that prints the path to the python executable.

    You can see the repo at:

    In build #98, run on Previous Windows Server 2012 R2, you can see the expected output at line 21.

    In build #99, in which the os line has been commented out of appveyor.yml, you can see that there is no output from

    Let me know if there is more you want me to do with this, and thanks for looking into it!

  12. Support Staff 12 Posted by Feodor Fitsner on 24 Jul, 2015 03:16 AM

    Feodor Fitsner's Avatar

    Hi Matt,

    Thanks for the sample - it was really helpful!

    The issue has been fixed and sample project works like a charm:

    We reassembled the image, but this time VS 2015 was installed with "Python tools" option disabled. VS 2013 Update 5 was not installed too, but I don't think it was an issue.

  13. 13 Posted by mattwcraig on 24 Jul, 2015 03:58 PM

    mattwcraig's Avatar

    Hi Feodor,

    Glad I could help -- I use appveyor everyday for open source projects!m


  14. 14 Posted by oconnor663 on 14 Dec, 2015 05:51 AM

    oconnor663's Avatar

    Hi Feodor, I think I'm running into the same issue Matt saw above. Is there any chance it's regressed since July? I'm seeing it on a minimal "hello world" example:

  15. Support Staff 15 Posted by Feodor Fitsner on 14 Dec, 2015 07:12 PM

    Feodor Fitsner's Avatar

    So, it's basically missing association for '.py` files, right? Will take a look.

  16. 16 Posted by oconnor663 on 14 Dec, 2015 07:31 PM

    oconnor663's Avatar

    I don't think so. When I look at the output of `assoc` and `ftype` in my tests, it looks good. (It's pointing to `C:\Windows\py.exe`, which isn't necessarily the right Python version for a given test, but anyway it should at least be executing something.) This sounds to me like what Matt mentioned above, where there was no difference in `assoc` and `ftype` between the configuration that worked and the configuration that didn't.

  17. 17 Posted by oconnor663 on 19 Dec, 2015 04:59 PM

    oconnor663's Avatar

    Any update, Feodor? I reran my example yesterday ( and it looks like `` is still failing to run, though `python` works fine.

  18. Support Staff 18 Posted by Feodor Fitsner on 20 Dec, 2015 03:49 AM

    Feodor Fitsner's Avatar

    Sorry, I'm still working on that.

  19. 19 Posted by oconnor663 on 21 Dec, 2015 07:03 PM

    oconnor663's Avatar

    Ok, I figured out a hack to get it working:

    The command I needed to run was:
    reg delete HKEY_CLASSES_ROOT\.py\OpenWithProgids /f

  20. Support Staff 20 Posted by Feodor Fitsner on 21 Dec, 2015 07:40 PM

    Feodor Fitsner's Avatar

    Good to know. Anyway, I believe the issue has been fixed in the latest build worker update we are going to deploy today.

  21. 21 Posted by oconnor663 on 21 Dec, 2015 09:45 PM

    oconnor663's Avatar

    Awesome, thanks Feodor.

  22. Support Staff 22 Posted by Feodor Fitsner on 22 Dec, 2015 12:45 AM

    Feodor Fitsner's Avatar

    .py mapping has been fixed on all build workers. Should be working without a registry fix.

  23. 23 Posted by oconnor663 on 22 Dec, 2015 04:16 AM

    oconnor663's Avatar

    Hmm, looks like the latest change re-broke my tests. Here's the previous (successful) build: And here's the latest (failing) build of the same commit:

    The tests are failing with syntax errors, so it looks like scripts that were previously running with Python 3 are now running with Python 2. What exactly changed?

  24. Support Staff 24 Posted by Feodor Fitsner on 22 Dec, 2015 04:19 AM

    Feodor Fitsner's Avatar

    Python 2.7.x has been always the default one in PATH. .py extension is mapped to Python 2.7. Or what's wrong?

  25. 25 Posted by oconnor663 on 22 Dec, 2015 04:42 AM

    oconnor663's Avatar

    I think Python is supposed to respect Unix-style shebang lines to determine the Python version, when launching via the C:\Windows\py.exe launcher. Maybe we changed the Python.File ftype to explicitly refer to Python 2?

  26. Support Staff 26 Posted by Feodor Fitsner on 22 Dec, 2015 04:50 AM

    Feodor Fitsner's Avatar

    Looks like I've associated .py with C:\python27\python.exe but it should be mapped to C:\Windows\py.exe.

    To change association add this line to your build script:

    - ps: cmd /c ftype Python.File="C:\Windows\py.exe" "%1" %*

    Let me know if that worked and I'll update environment.

  27. 27 Posted by oconnor663 on 22 Dec, 2015 05:08 AM

    oconnor663's Avatar
  28. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 02:03 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac