-
Notifications
You must be signed in to change notification settings - Fork 253
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
Fix deprecation warning on Python 3.11 #193
Conversation
I ran tests on Python 3.7+ locally, checking for warnings, with:
None emitted. Edit: I've also pushed |
298b80a
to
33d24fe
Compare
Probably #167 should be merged first. |
@adamchainz #167 has been merged. |
Rebased! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3.6 is now EOL, so you could just drop the final fallback & support for 3.6 -- every upstream supported version has a version of importlib.resources
.
A
Not every supported version has the same API in the standard library because it's API is explicitly not stable until maybe 3.10. The fallback is necessary unless we drop everything<3.10 and even then there's a commitment to moving the API quickly to something "better" if something seemingly better is identified without concern for stability promises |
Sorry, by the final fallback I meant the A |
It changed after that, and may change in 3.12, 3.13 or some other future version |
Okay, I've dropped Python 3.6 support, added the 3.11 tag, and removed the Python <3.7 branch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This suggests inlining contents()
into the version checks using the native importlib.resources
APIs, rather than coercing to a filesystem path.
I can't put a GH suggestion to delete the top level contents()
as it covers added and deleted lines.
A
Squashed everything together, ready for merge. |
Will this also fix #131 ? I think this will also actually fix #170, #183, #184, and #190 which were closed without being fixed. Thank you for this work @adamchainz ! Not sure why 5th time is the charm, but I am grateful #192 was not also closed as a duplicate and your PR is being considered. Can the simpler #147 be reconsidered (I think this is what @AA-Turner was suggesting?) |
Unfortunately python 3.6 still represents 15% of our downloads, so I think I speak for all the maintainers when I say we're going to be hesitant about the tradeoffs of fixing deprecation warnings by dropping support for such a large group of users. |
Would the PR be accepted if it incorporated the filesystem branch? A |
Meaning it maintained support for Python 3.6? Yes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested changes restore 3.6 compat. (untested)
A
python-version: ["3.6", "3.7", "3.8", "3.9", "3.10"] | ||
|
||
python-version: | ||
- "3.7" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- "3.7" | |
- "3.6" | |
- "3.7" |
@@ -46,19 +46,20 @@ | |||
include_package_data=True, | |||
zip_safe=False, | |||
license='MPL-2.0', | |||
python_requires=">=3.6", | |||
python_requires=">=3.7", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
python_requires=">=3.7", | |
python_requires=">=3.6", |
classifiers=[ | ||
'Development Status :: 5 - Production/Stable', | ||
'Intended Audience :: Developers', | ||
'License :: OSI Approved :: Mozilla Public License 2.0 (MPL 2.0)', | ||
'Natural Language :: English', | ||
'Programming Language :: Python', | ||
'Programming Language :: Python :: 3', | ||
'Programming Language :: Python :: 3.6', | ||
'Programming Language :: Python :: 3 :: Only', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'Programming Language :: Python :: 3 :: Only', | |
'Programming Language :: Python :: 3 :: Only', | |
'Programming Language :: Python :: 3.6', |
def contents() -> str: | ||
return files("certifi").joinpath("cacert.pem").read_text(encoding="ascii") | ||
|
||
else: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
else: | |
elif sys.version_info >= (3, 7): |
def contents() -> str: | ||
return read_text("certifi", "cacert.pem", encoding="ascii") | ||
def contents() -> str: | ||
return read_text("certifi", "cacert.pem", encoding="ascii") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return read_text("certifi", "cacert.pem", encoding="ascii") | |
return read_text("certifi", "cacert.pem", encoding="ascii") | |
else: | |
import os | |
import types | |
from typing import Union | |
Package = Union[types.ModuleType, str] | |
Resource = Union[str, "os.PathLike"] | |
# This fallback will work for Python versions prior to 3.7 that lack the | |
# importlib.resources module but relies on the existing `where` function | |
# so won't address issues with environments like PyOxidizer that don't set | |
# __file__ on modules. | |
def read_text( | |
package: Package, | |
resource: Resource, | |
encoding: str = 'utf-8', | |
errors: str = 'strict' | |
) -> str: | |
with open(where(), encoding=encoding) as data: | |
return data.read() | |
# If we don't have importlib.resources, then we will just do the old logic | |
# of assuming we're on the filesystem and munge the path directly. | |
def where() -> str: | |
f = os.path.dirname(__file__) | |
return os.path.join(f, "cacert.pem") |
@Lukasa Can we please merge this? This seems to be a blocker for enabling us to test against py311 as we treat warnings as errors. |
This PR breaks Python 3.6 support as-is. We have said several times that it will not be considered until 3.6 support is restored. |
@alex py36 reached end-of-life more than 6 months ago, why not just dropping it? If someone wants to maintain it, it can be done in a maintenance branch. IMHO, we should to hinder main (brand) development on a dead snake, especially as it can be quite tricky to keep compatibility across a wide range of python versions. The way I see it is that original PR is more than two months old and soon we might end-up not having a certify for python 3.11 if we don't fix it. What is worse? Still, if agreed, removal of support for py36 should be done in a separated change. |
Python 3.6 reflects a greater percent of our downloads than either Python 3.9 or 3.10. |
Please see PR #199, which is the same as this with @AA-Turner's suggestions applied to retain 3.6 support. |
Here's the download share for different versions, 3.6 is the third biggest chunk: |
Thanks for addressing it. Regarding downloads stats, please be aware that they might be painting a picture very different than what people writing code might attempt to use.
That is why I suggested moving an old version to a maintenance branch, so if someone really needs a fix, they would have to backport it, likely having to make other changes to do so, maybe even sponsor/pay maintainers to get it done. I am a maintainer myself and I consider myself (morally) responsable to help others that contribute back. When it comes to support "old" stuff, that is where you can be picky. I seen some very small projects keeping compatibility with only 2 versions of python but that is extreme. Obviously that "certify" is an AAA class project, at least as popularity, not budget, so doing that would be insane. Again, a bit thanks to all involved! |
It is incorrect that not having wheels impacts download stats. PyPI download stats are computed using the Python version doing the install, from its user agent, not based on the Python version a wheel targets. Indeed, certifi only publishes universal wheels. Further, neither Python 3.9 nor 3.10 are buggy, so we wouldn't expect that to depress download counts. While its true that many downloads come from CI systems, these are nonetheless systems that would be impacted by dropping a Python version. Finally, a maintenance branch makes little sense for this project, given that our primary purpose is to distribute a PEM file. It's not even clear to me how we'd version such a branch. |
I totally agree with you. Probably this project is the best use-case against using a maintenance branch, as it basically packages a single data file, nothing else. |
Any chance of doing a patch release so we can start using with py311? I would prefer to not have to add an ignore for the fixed runtime warning. |
Fixes #192.