Skip to content
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

Drop Python 3.7 support #1616

Closed
hmaarrfk opened this issue Feb 23, 2022 · 9 comments
Closed

Drop Python 3.7 support #1616

hmaarrfk opened this issue Feb 23, 2022 · 9 comments
Labels

Comments

@hmaarrfk
Copy link
Contributor

Your question:

In accordance to the suggestions made in nep29, some packages have started dropping support for python 3.7.

https://numpy.org/neps/nep-0029-deprecation_policy.html#drop-schedule

Given that Python 3.10 is rolling out, it seems like it would make sense to stop generating packages for python 3.7 by default to limit the size of the build matrix and to encourage the open source community to move forward.

Thoughts?

xref: Imagecodecs dropping 3.7 support upstream cgohlke/imagecodecs#34

@dopplershift
Copy link
Member

I'm actually fine with doing it and have no stake since my projects have dropped 3.7. Having said that

encourage the open source community to move forward.

I'm not a fan of this line of reasoning and IMO it's not conda-forge's place to be pushing people along the upgrade path.

@jakirkham
Copy link
Member

Typically we have only dropped Python versions when adding a new one. Usually this has happened when the older version was nearing or reaching EOL.

While the Scientific Python/PyData ecosystem is an important use case for conda-forge and its users, they are not the only users. So am somewhat reluctant to adopt a policy from some users and applying them to all users.

@hmaarrfk
Copy link
Contributor Author

older version was nearing or reaching EOL

Understood. I can simply drop support on the packages that start to drop them.

@jakirkham
Copy link
Member

I can simply drop support on the packages that start to drop them.

Yeah that we can always do :)

@hmaarrfk hmaarrfk reopened this Feb 23, 2022
@hmaarrfk
Copy link
Contributor Author

Followup question.

For upstream packages that are dropping python 3.7, what should we do about pypy? pypy is "3.7" with more bells and whistles.

@jakirkham
Copy link
Member

For upstream packages that are dropping python 3.7, what should we do about pypy? pypy is "3.7" with more bells and whistles.

Short term: If Python 3.7 is dropped, then that would mean all Python builds that are 3.7 based would be dropped. Not sure there is much we can do about that if Python 3.7 is no longer supported in a release. If we want to maintain some kind of support, we could add a branch for the last release that still supports Python 3.7 and maintain that (though this can be done as needed).

Medium term: There is discussion about PyPy 3.8 in issue ( conda-forge/conda-forge-pinning-feedstock#2089 ). Once ready, adding PyPy 3.8 would then provide a PyPy option.

@hmaarrfk
Copy link
Contributor Author

thank you

@ngam
Copy link
Contributor

ngam commented Jul 29, 2023

Did we ever manage to have a wide policy on this? People are dropping python 3.8 now...

https://numpy.org/neps/nep-0029-deprecation_policy.html

Jun 23, 2023 | 3.9+ | 1.22+

@jakirkham
Copy link
Member

Please see this comment: conda-forge/conda-forge-pinning-feedstock#2623 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

4 participants