Use a minimal Windows docker container to check the wheels

[ogrisel]

Such a minimal windows test environment should have no C/C++ compiler installed, nor SDK, nor redistributable runtime such as c:\Windows\System32\vcomp140.dll nor even Miniconda. Indeed Miniconda ships its own bunch of system dlls such as vcomp140.dll by default.

The goal would be to detect problems such as scikit-learn/scikit-learn#15899 before releasing.

Instead it should install Python from https://www.python.org (e.g. an embedded zip or from the .msi installer which can be installed from the command line).

We should probably do that based on #23 as the current AppVeyor worker is really too slow to iterate with.

A minimal test environment is probably achievable using a Windows servercore container although I have never tried myself.

References

Powershell script to download install python .msi from python.org:
https://github.com/ogrisel/python-appveyor-demo/blob/master/appveyor/install.ps1#L104

Windows containers on Azure Pipelines:
https://docs.microsoft.com/en-us/azure/devops/pipelines/process/container-phases?view=azure-devops&tabs=yaml#windows-containers

[ogrisel]

Ping @jeremiedbb @thomasjpfan :)

[thomasjpfan]

I agree this would be good.

I will update #23 when #43 and scikit-learn/scikit-learn#15929 gets resolved.

[jnothman]

Should this be contributed back to multibuild?

[ogrisel]

Indeed, although it might be CI platform specific.

[ogrisel]

Now that we have switched to use cibuildwheel in the master repo, we might want to develop this there instead.

[ogrisel]

cc @alfaro96.

[alfaro96]

Is the idea to have a Windows Docker container (servercore) to manually install Python (using a .zip or .msi file) and then install the (Windows) wheels and run the tests to ensure that we properly vendor the vcomp140.dll file?