Use only vcpkg for static windows build

[pavelzw]

I suggest we switch to vcpkg completely for the windows static build process for micromamba. This makes the build pipeline for windows more maintainable since the dependencies in vcpkg are actively maintained not only by mamba-org. Also, fewer weird errors occur when building outside of a conda environment with MSVC.

This also allows us to use windows-latest instead of windows-2019.

The build time for static win-64 sinks from 40min down to 7min or 2min with sccache (as long as the vcpkg dependencies are cached which is now easier outside of a conda env).

[jonashaag]

Thanks a lot for working on this!

I wonder if there is a way to share the build instructions with the feedstock. Maybe we can use the feedstock bld.bat?

[JohanMabille]

This makes the build pipeline for windows more maintainable since the dependencies in vcpkg are actively maintained not only by mamba-org.

The dependencies on conda-forge are not maintained by mamba-org devs only.

Also, fewer weird errors occur when building outside of a conda environment with MSVC.

Which means we would not be able to catch conda build errors before trying to build the feedstock.

I agree that reducing the build time for windows static build is more than required; however we should definitely have an automatic way to test micromamba feedstock at least before releasing. Maybe a pre-release branch with the feedstock build triggered on it would be an acceptable solution.

On the long run, the goal would be to have all the static dependencies correctly packaged on conda-forge so that we can have a full static build without needing vcpkg at all (but that's another story).

[JohanMabille]

So here is my suggestion: let's merge #2526 to fix the CI, then merge #2512 and other stuff when ready so that we can quickly push out a release.

Then we merge this one and setup the CI so that it is possible to test the feedstock before releasing.

[pavelzw]

Maybe a pre-release branch with the feedstock build triggered on it would be an acceptable solution.

Seems reasonable to me 👍🏻
Unfortunately, I haven't found a way to reliably replicate the conda-forge environment using GitHub Actions or my own Windows machines... The azure runners seem to behave a bit differently than windows-2019 (That's also the reason why the current windows static build on main is not using conda-build but does the steps manually)

[pavelzw]

@JohanMabille should we merge this now then?

[JohanMabille]

@pavelzw sorry for this super late answer, your notification was drowned in the mass and the last weeks were quite intense. Happy that this was merge!

[pavelzw]

No worries 👍🏻