Dropping Python 3.7

[dopplershift]

We've reached a point where the NEP29 suggestion for dropping 3.7 (December 2021) is much different from the official EOL (June 2023). We probably should decide what the policy is actually going to be, since it's becoming a relevant question for some builds.

#1947 seemed to indicate some confusion on whether we're following NEP29 or not.

[hmaarrfk]

I thought we had this discussion and an important point was to ensure that we worked with the non-scientific community as well:
conda-forge/conda-forge.github.io#1616

[dopplershift]

Thanks, I had forgotten about that issue. I think there is still an issue with actually firmly establishing what our schedule/policy will be going forward. The issue I linked above is a practical case of:

1. Needing to rebuild an older version against our updated pins due to upstream moving on
2. Confusion about whether we're following NEP29 or not

So while that issue indicates we shouldn't drop it now, there's still a question of: when are we dropping 3.7? What are we doing when 3.11 comes out? (Beta 1 drops first week of May, official release 5 months later)

[jakirkham]

Typically we've dropped an old version when adding a new one.

[chrisburr]

I don't think we necessarily need a formal policy for this do we? In the case of Python 3.6 it made sense as end of life was close and it was an issue for the OpenSSL migration (only 3.7+ supports OpenSSL 3).

When 3.11 is released we might want to reduce the size of the build matrix, especially for ppc64le/aarch64. That said, I'd also be happy with keeping it for another year given that Python is moving towards having 5 years of support and one release per year. Especially as it seems to be getting a decent number of downloads for the latest patch.

Regardless, if an issue arises that causes Python 3.7 support to become annoying we should keep the option for dropping it sooner.

[jakirkham]

Not a formal one, but informally we have tended to keep 3 Python versions around and drop the oldest one when adding a new one. There may be other reasons like approaching EOL or other assessed costs. The reason for this informal policy is as you say keeping the build matrix reasonable.

Individual packages as always can drop support for things they no longer support or things that cause issues.

[isuruf]

As discussed in the core meeting today, let's drop 3.7 when 3.11 comes out and we start the migration in October. We can make an announcement and people can voice their concerns in this issue.

[jakirkham]

Submitted PR ( conda-forge/conda-forge.github.io#1815 ) to announce the intention to drop Python 3.7

Edit: Here is the announcement entry.

[bkpoon]

Will there be a way to still build Python 3.7 versions of a package on the conda-forge channel by modifying conda_build_config.yaml? We have users that use conda packages in Google Colab notebooks with condacolab and write algortihms integrating with AlphaFold (machine learning for structural biology). As of today, both are still on Python 3.7. Thanks!

[jakirkham]

@jakevdp, do you know who we should talk to about updating Google Colab's Python version?

[jakevdp]

I would ask on this issue: googlecolab/colabtools#2165 One of the Colab team members might be able to repond there regarding the current ETA.

[jakirkham]

Thanks for the speedy reply, Jake! 😄

Have posted a comment here ( googlecolab/colabtools#2165 (comment) ) asking for an ETA as well as outlining the situation. Others should feel free to include additional info.

[bkpoon]

It looks like the update might be intertwined with an update to the Ubuntu image (googlecolab/colabtools#1880). I guess we'll wait and see.

We might switch to binder, but we'll miss the GPU.