Support for Python versions for upcoming 4.0 release

[munkm]

Description

Numpy 1.20 officially drops support for Python 3.6, but in our last team meeting we agreed that yt4.0 would support python 3.6.

How do we want to proceed with this?

• Pin to <1.20 until the release and pause explicit support development for 1.20 until after 4.0 is released?
• Drop support for 3.6 for the 4.0 release (we just dropped python 2.7 with the yt 3.6 release)
• Something else?

[matthewturk]

Can you think of any way to get usage info for various python versions among the community?

[neutrinoceros]

My understanding is that we have no reason to break compatibility right now, it's only relevant if we want to actually push using 3.7+ exclusive features. Type-hints are the only one that we discussed so far (they actually exist in Python 3.6 too but the level of support is too low there IMO).
The fact that numpy 1.20 broke compat means that our users can't upgrade to the latest version of bumpy (coincidently, the one we're running our tests against) unless they switch to python 3.7 or greater, but it doesn't make yt de facto incompatible with 3.6

All this considered, I don't think we need to pin numpy, but I vote for dropping Python 3.6 after yt 4.0 nonetheless :)

[matthewturk]

Oh! Right, so numpy will take care of this itself, and as long as we don't require 1.20 or py3.7 specific stuff, we're OK?

…

On Wed, Feb 10, 2021 at 9:35 AM Clément Robert ***@***.***> wrote: My understanding is that we have no reason to break compatibility *right now*, it's only relevant if we want to actually push using 3.7+ exclusive features. Type-hints are the only one that we discussed so far (they actually exist in Python 3.6 too but the level of support is too low there IMO). The fact that numpy 1.20 broke compat means that our users can't upgrade to the latest version of bumpy (coincidently, the one we're running our tests against) unless they switch to python 3.7 or greater, but it doesn't make yt de facto incompatible with 3.6 All this considered, I don't think we need to pin numpy, but I vote for dropping Python 3.6 after yt 4.0 nonetheless :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3070 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAVXO6CR4HINQSSKN3SZVTS6KRSVANCNFSM4XNEIE6Q> .

[neutrinoceros]

and as long as we don't require 1.20 or py3.7 specific stuff, we're OK?

On paper yes. The one issue with that plan is that numpy 1.20 introduced an infamous eisenbug in our CI so one could argue we should not explicitly support numpy 1.20 for that reason. my personal opinion is that it's... probably fine™️

[munkm]

as long as we don't require 1.20 or py3.7 specific stuff, we're OK?

Yep! This is my understanding. I felt it was important to raise this so that we're all aware of this to avoid 3.6 breakage until later.

so one could argue we should not explicitly support numpy 1.20 for that reason. my personal opinion is that it's... probably fine™️

I think this is true too. We don't necessarily have to pin to <1.20, but we can avoid adding explicit support for it until later.

[neutrinoceros]

Update: we've been having fatal issues with every single minor release of numpy and matplotlib in the recent past.
They are usually easy-ish to fix, but I now think that we should add upper limits to supported versions in setup.py/setup.cfg (setup.cfg is the future but the migration PR hasn't landed yet. edit: done (#3236)) when we release yt, to reflect the currently tested versions for numpy and matplotlib. Other dependencies are better behaved and break stuff much less often, so I think it's safe not to add upper limits everywhere.

Adding an explicit upper limit to supported Python version doesn't provide any edge that I can think of.
The only limitation we have comes from our dependencies, and we don't want to add another barrier: when numpy publishes wheels for Python 3.10, yt users should immediately be able to leverage them.

[neutrinoceros]

I did everything I could in #3380 to mitigate or eliminate future breakage. Python 3.12 is a known future incompatibility at this point, so it is currently being excluded. This is intended to be fixed in yt 4.1, see #3384 .