-
-
Notifications
You must be signed in to change notification settings - Fork 280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Azure deprecating windows-2016 environment #1538
Comments
Do we know of any particular reason why we can't move to |
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? |
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. |
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 |
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. |
I remember that part, and it's (by now?) also nicely documented.
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). |
Yes. |
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:
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. |
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. |
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. |
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. |
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 |
Still need to fix staged-recipes. |
Thanks all! 😄 Any other items outstanding here? |
JFYI saw this message pop up on Azure recently
|
Do you remember where? Through smithy and staged-recipes at least everything touching recipes should be updated. |
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) 🙂 |
That would make sense. 😂 Maybe we can add pinned issue here until this is over? Just so that it’s easier to find. |
Seeing this warning on CI:
actions/runner-images#4312
The text was updated successfully, but these errors were encountered: