DEP: drop support for msvc<=1900 and Interix #22139
Conversation
|
Thanks Matti! Though what Matthew & I were saying was to drop |
|
Ah, I got confused by the title, sorry; the diff actually makes much more sense. |
Co-authored-by: h-vetinari <h.vetinari@gmx.com>
|
As long as we are at it, I wonder if we can drop numpy/numpy/core/src/common/npy_config.h Lines 140 to 148 in b6a3e83 |
|
This should probably be mentioned in |
That is a question for @DWesl |
| @@ -0,0 +1,5 @@ | |||
| * Support for Visual Studio 2015 has been removed. Please update to at least | |||
| Visual Studio 2019. | |||
There was a problem hiding this comment.
Since we're still building with vc141 and it is Visual Studio 2017 that defaults to that toolchain, I think that is what you want to say here. Otherwise, please make it explicit: you must use at least Visual Studio 2019 (then the first sentence should say 2017 not 2015), and you must use at least the vc141 compiler toolchain.
There was a problem hiding this comment.
I think mandating a lower bound that contains a non-default toolset makes little sense. Either vs2017+vc141 or vs2019+vc142.
In the previous discussions on this, one of the last relevant constraints for moving to vc142 (as I understood it) was conda-forge still being on vc141. That's being changed now, so from that POV - and as I understood it - a move to vc142 would be possible, notwithstanding that the CI isn't at that point yet.
There was a problem hiding this comment.
I think mandating a lower bound that contains a non-default toolset makes little sense. Either vs2017+vc141 or vs2019+vc142.
Agreed
That's being changed now, so from that POV - and as I understood it - a move to vc142 would be possible,
It's not, vc141 is a hard requirement until we get rid of SciPy depending on libnpymath at least.
There was a problem hiding this comment.
That's being changed now, so from that POV - and as I understood it - a move to vc142 would be possible,
It's not,
vc141is a hard requirement until we get rid of SciPy depending onlibnpymathat least.
If this is about the mingw / gfortran interaction, the issue with the unknown assembly section can be solved with a single flag to the same effective level of (non-)support
There was a problem hiding this comment.
Do you have a link for how to make the mingw-w64 toolchain work with vc142? I may have missed that part.
There was a problem hiding this comment.
Sure, see this comment and preceding discussion.
There was a problem hiding this comment.
Support for the flag and vc142 was added in #21360. All of our windows CI jobs
Line 255 in 555c07f
numpy/.github/workflows/wheels.yml
Lines 76 to 77 in 555c07f
<=2015
There was a problem hiding this comment.
Support for the flag and vc142 was added in #21360.
Hmm, I just spent a lot of time doing archeology to determine exactly which versions to avoid for SciPy wheel builds because they were built with vc142 (answer: 1.21.4, 1.21.5, 1.22.0 and 1.22.1). If we now went back to vc142 again but with a different flag, it would be great to record that somewhere prominent (e.g., the release notes, or a central doc page), because next time it'll perhaps be even harder to figure out.
|
@rgommers 1.21.6 should be good, it used 1.41. |
People show up on the mailing list with versions old enough to predate the current error message; after a a year or two where I heard people reply with "that version of the message is a decade old; update your system or tell whomever maintains the software you're trying to run to update theirs" they set up an autoresponder. I suspect those people aren't building their own NumPy, though. Of the questions from developers, there was someone with Cygwin 1.5 a few years back (I think pre-3.0, possibly pre-2.0), but the official Cygwin stance is that it's a rolling distribution and one of the first suggestions for someone having problems is asking them to update their system to see if the problem goes away (sometimes they haven't updated for a week or three and it does help, other times they need to install a snapshot instead). I don't think there will be people holding off on updating to 3.2 or 3.3 the way they might 3.0 (dropped XP maybe? I think 2.0 was the username overhaul, but I don't remember what happened for 3.0) or 3.4 (drops support for 32-bit and Vista), so you're probably fine dropping those bits now. |
|
Thanks for the context @DWesl, very useful. I didn't know it was a rolling distribution. So it sounds like we're good to drop <3.3 support. |
Remove support for MSVC<=1900 (visual studio 2015 and older) and the Interix POSIX support package.
See this comment thread
xref @h-vetinari, @matthew-brett
Release note needed, I will add it in another commit