Azure deprecating windows-2016 environment

[jakirkham]

Seeing this warning on CI:

##[warning]The windows-2016 environment will be deprecated on November 15, 2021, and removed on March 15, 2022. Migrate to windows-latest instead. For more details see https://github.com/actions/virtual-environments/issues/4312

actions/runner-images#4312

[mariusvniekerk]

Do we know of any particular reason why we can't move to windows-latest?

[isuruf]

We'll need to see if vc141 toolchain works there.

[h-vetinari]

We'll need to see if vc141 toolchain works there.

From a quick google search, this looks like it should be possible.

Out of curiosity, would it not be possible to migrate all feedstocks to vs2019 - not sure where the dependence on the 2017 toolchain comes in? Or is that to keep support for running on older windows versions?

[isuruf]

Out of curiosity, would it not be possible to migrate all feedstocks to vs2019 - not sure where the dependence on the 2017 toolchain comes in? Or is that to keep support for running on older windows versions?

This came up with vs2015 -> vs2017 migration too. To link packages built with vc141 and vc142, you need vc142. So we'll be asking all of our users (for eg: people building their own python extensions) to migrate to vc142 which is not desirable.

[mariusvniekerk]

From the specs here https://github.com/actions/virtual-environments/blob/main/images/win/Windows2019-Readme.md it looks like that image has VC.141 bits installed so we might be able to keep using it. It does not include VS2017

[isuruf]

Sure. We don't particularly need VS2017. Just the vc141 toolchain. Just need someone to try that compiling stuff works and that the vc141 toolchain is used.

[h-vetinari]

To link packages built with vc141 and vc142, you need vc142.

I remember that part, and it's (by now?) also nicely documented.

So we'll be asking all of our users (for eg: people building their own python extensions) to migrate to vc142 which is not desirable.

Just so I understand correctly, this is talking about people having (e.g.) a conda environment to work on a given python project (say, pandas), and not forcing them to upgrade their toolchain, right? Because other than that, I'm not aware of other usecases that would be exposed to such linker constraints (with my understanding that the vast majority of cf-user downloads a set of self-contained binaries).

[isuruf]

Just so I understand correctly, this is talking about people having (e.g.) a conda environment to work on a given python project (say, pandas), and not forcing them to upgrade their toolchain, right?

Yes.

[h-vetinari]

Just playing devil's advocate here, but would moving to vc142 really be so disruptive? Said otherwise, Microsoft itself (whether through Azure or Github) is making vs2017 a non-viable option, and if a given project is being tested (much less developed) on windows, they'll have to move on just as well?

In yet other words - how many people:

• are working on a project that needs windows support
• are not themselves affected by Microsoft's deprecation & removal of the windows-2016 image (e.g. using AppVeyor?!)
• are developing (primarily) on windows
• are using conda environments to work locally
• cannot use older (vc141-compatible) builds in their environment**
• cannot upgrade their toolchain

To me that number sounds pretty low, and similarly for the "pain" of moving to an ABI-compatible toolchain upgrade. Certainly low enough that it's IMO worth considering whether conda-forge should really try to bridge a gap that Microsoft itself is intentionally creating.

** minimum build dependencies move very slowly for most projects, i.e. old builds would be fine to keep developing for quite a while.

[isuruf]

Said otherwise, Microsoft itself (whether through Azure or Github) is making vs2017 a non-viable option

How is that relevant here? Previous comments have explained that we can use vc141 toolchain with VS2019. We can even use vc140 toolchain (VS2015's default toolchain) with VS2019.

[h-vetinari]

Said otherwise, Microsoft itself (whether through Azure or Github) is making vs2017 a non-viable option

How is that relevant here?

Microsoft is pushing people away from vs2017 (default: vc141) to vs2019 (default: vc142) and later. If it's easy to keep running the old toolchain on vs2019, great! I'm just trying to understand (and make transparent) the trade-offs, because if the effort to keep using vc141 turns out to be high, then it becomes relevant.

[isuruf]

There's no trade-off. We just need to make sure that the conda compiler activation script works. The effort needed is probably less than the time we have spent on writing on this issue.

[h-vetinari]

I think this issue has been dealt with by conda-forge/conda-smithy#1552, which is part of the newest conda-smithy 3.15.1

[isuruf]

Still need to fix staged-recipes.

[BastianZim]

Fixed

conda-forge/staged-recipes#17236

[jakirkham]

Thanks all! 😄 Any other items outstanding here?

[jakirkham]

JFYI saw this message pop up on Azure recently

A brownout will take place on January, 11 3:00 PM - 4:00 PM UTC to raise awareness of the upcoming windows-2016 environment removal. For more details, see actions/runner-images#4312

[BastianZim]

Do you remember where? Through smithy and staged-recipes at least everything touching recipes should be updated.

[jakirkham]

A feedstock still needing a re-render 😂

Not seeing it after the re-render. So should be limited to feedstocks still needing a re-render. Still good to keep in mind in case others show up with an issue during that window (as a re-render should fix the issue) 🙂

[BastianZim]

That would make sense. 😂

Maybe we can add pinned issue here until this is over? Just so that it’s easier to find.