DEP: drop support for msvc<=1900 and Interix

[mattip]

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

[h-vetinari]

Thanks Matti!

Though what Matthew & I were saying was to drop msvc<1920, not 1900.

[h-vetinari]

Ah, I got confused by the title, sorry; the diff actually makes much more sense.

[mattip]

As long as we are at it, I wonder if we can drop cygwin < 3.3. 3.3 was released Oct 2021, 3.2 in late March 2021. How common is it for people to be using an older version?

numpy/numpy/core/src/common/npy_config.h

Lines 140 to 148 in b6a3e83

	#if CYGWIN_VERSION_DLL_MAJOR < 3003
	/* https://cygwin.com/pipermail/cygwin-announce/2021-October/010268.html */
	/* Builtin abs reports overflow */
	#undef HAVE_CABSL
	#undef HAVE_HYPOTL
	#endif
	#if CYGWIN_VERSION_DLL_MAJOR < 3002
	/* https://cygwin.com/pipermail/cygwin-announce/2021-March/009987.html */

[charris]

This should probably be mentioned in doc/HOWTO_RELEASE. Might also want to update the OS X there when the switch to 10.15 is made. Are there other places where Windows compilers are mentioned?

[rgommers]

As long as we are at it, I wonder if we can drop cygwin < 3.3. 3.3 was released Oct 2021, 3.2 in late March 2021. How common is it for people to be using an older version?

That is a question for @DWesl

[rgommers]

LGTM modulo a minor comment on the wording of the release note.

[rgommers]

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.

[h-vetinari]

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.

[rgommers]

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.

[h-vetinari]

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.

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

[rgommers]

Do you have a link for how to make the mingw-w64 toolchain work with vc142? I may have missed that part.

[h-vetinari]

Sure, see this comment and preceding discussion.

[mattip]

Support for the flag and vc142 was added in #21360. All of our windows CI jobs

numpy/azure-pipelines.yml

Line 255 in 555c07f

vmImage: 'windows-2019'

and

numpy/.github/workflows/wheels.yml

Lines 76 to 77 in 555c07f

	- [windows-2019, win_amd64]
	- [windows-2019, win32]

run on windows 2019 images with Visual Studio 2019. I would prefer not to recommend out-of-date software. I could just drop the whole sentence, recommendations are not really not part of a release note. The important part is that we are dropping <=2015

[mattip]

Updated.

[rgommers]

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]

Let's give this a go, thanks @mattip

[charris]

@rgommers 1.21.6 should be good, it used 1.41.

[DWesl]

As long as we are at it, I wonder if we can drop cygwin < 3.3. 3.3 was released Oct 2021, 3.2 in late March 2021. How common is it for people to be using an older version?

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.

[rgommers]

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.