Fix httpbin on AppVeyor CI

[vadz]

httpbin is broken again (and probably since quite some time) on AppVeyor: with master version it uses Python 3.5 for which there are apparently no wheels (binaries) any more, and so pip tries to build the native dependencies itself and fails miserably as seen in this log, with the relevant part being

   C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\link.exe /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:c:\python35\libs /LIBPATH:c:\python35\PCbuild\win32 "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB" "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB" "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.22621.0\ucrt\x86" "/LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x86" "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.22621.0\um\x86" /EXPORT:PyInit__cffi_backend build\temp.win32-3.5\Release\c/_cffi_backend.obj build\temp.win32-3.5\Release\c/libffi_x86_x64\ffi.obj build\temp.win32-3.5\Release\c/libffi_x86_x64\prep_cif.obj build\temp.win32-3.5\Release\c/libffi_x86_x64\types.obj build\temp.win32-3.5\Release\c/libffi_x86_x64\win32.obj /OUT:build\lib.win32-3.5\_cffi_backend.cp35-win32.pyd /IMPLIB:build\temp.win32-3.5\Release\c\_cffi_backend.cp35-win32.lib
       Creating library build\temp.win32-3.5\Release\c\_cffi_backend.cp35-win32.lib and object build\temp.win32-3.5\Release\c\_cffi_backend.cp35-win32.exp
    Generating code
    Finished generating code
    LINK : fatal error LNK1158: cannot run 'rc.exe'
    error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\link.exe' failed with exit status 1158

I've tried switching to Python 3.8 in #23388, but it still doesn't work: with this Python version it uses binaries, but they don't work, as seen in this log, with the actual error being

  File "C:\Python38\lib\runpy.py", line 185, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "C:\Python38\lib\runpy.py", line 111, in _get_module_details
    __import__(pkg_name)
  File "C:\Python38\lib\site-packages\httpbin\__init__.py", line 3, in <module>
    from .core import *
  File "C:\Python38\lib\site-packages\httpbin\core.py", line 22, in <module>
    from werkzeug.wrappers import BaseResponse
ImportError: cannot import name 'BaseResponse' from 'werkzeug.wrappers' (C:\Python38\lib\site-packages\werkzeug\wrappers\__init__.py)

How is it possible for the official package manager of one of the most used programming languages to install a broken package? I really have no idea, but I just can't keep fighting with Python ecosystem any more, so I simply gave up. If anybody else is brave enough to figure out what's going on here, please do, as it would be nice to be able to run wxWebRequest unit tests in the CI builds, but I'm too fed up with it to do it.

[swt2c]

The crux of the issue is that httpbin has been unmaintained for 5 years. Meanwhile the rest of the Python ecosystem has moved on, and httpbin's metadata hasn't been updated to report that it can't work with newer dependencies (or better yet, just fixed to work with those newer dependencies).

I think that #23392 might fix it, whenever AppVeyor gets around to trying it.

[vadz]

The crux of the issue is that httpbin has been unmaintained for 5 years.

I understand this, but it's still incredible how often things that used to work previously spontaneously break in Python land without any warning. I can accept that things that used to work on an older system or with an older Python version don't work on a newer one, but here, and not for the first time, something that used to work just stopped one day, without anything changing locally (AppVeyor didn't update their image, it's just that Python 3.5 wheels have disappeared, I think).

I think that #23392 might fix it

Thanks a lot for fixing it, I really appreciate it.

[swt2c]

The crux of the issue is that httpbin has been unmaintained for 5 years.

I understand this, but it's still incredible how often things that used to work previously spontaneously break in Python land without any warning. I can accept that things that used to work on an older system or with an older Python version don't work on a newer one, but here, and not for the first time, something that used to work just stopped one day, without anything changing locally (AppVeyor didn't update their image, it's just that Python 3.5 wheels have disappeared, I think).

I didn't see the logs for Python 3.5, so I can't comment on what happened there. Python 3.5 went EOL around 2.5 years ago so maybe that had something to do with it.

The recommended solution, if you don't want to things to ever change, is to pin all of the requirements.