Build micromamba win with feedstock

[AntoinePrv]

No description provided.

[AntoinePrv]

@pavelzw any idea how to get the "Micromamba static builds" started?

[pavelzw]

My suggestion would be to use only vcpkg for static builds and avoid going through the pain of static builds with conda-build for windows 😅

The static builds with only vcpkg have cause way fewer issues than trying with conda-build. I don't see the value of trying to port this to conda-build.

Personally, I would just leave the static CI with windows be and try to migrate the release workflow to actually use this build instead of the conda-forge static binaries as discussed in #2595.

[AntoinePrv]

This is not DRY, we need to sync the feedstock and this CI constantly. VCPKG has caused a lot of outages too. Conda-Forge takes more pain to setup I agree but once it is setup it's stable and simple, no need for extra cache etc. We also need to work with two systems, which is not convenient, because were are not gonna stop shipping libmambapy.

[pavelzw]

But how about trying to get rid of the vcpkg dependency in the recipe first? You already did the (hopefully 😅) most painful part by moving the libsolv dependency to conda-forge.

[AntoinePrv]

Fair enough. How about trying adding a light environment and starting to also used the libs that are properly packaged statically?

[AntoinePrv]

Great this seems to be working. The point is I am adding some more dependencies and don't want to do the work twice.

@pavelzw

• Do you know if these are deployed anywhere? If so I might be more reluctant to do mixed builds here (but I would also encourage to take the builds from conda-forge).
• Can we remove entries from vcpkg.json, or should we keep that file complete because it is used elsewhere?

[AntoinePrv]

Being pragmatic, this is the easiest way to fix the CI and discrepancies between yaml-cpp packages.