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

Fix certifi.where() to use importlib.resources where available #123

Merged
merged 1 commit into from Apr 6, 2020

Conversation

dstufft
Copy link
Contributor

@dstufft dstufft commented Apr 5, 2020

No description provided.

@dstufft dstufft changed the title Use the importlib.resources backport on older versions of Python Fix certifi.where() to use importlib.resources where available Apr 5, 2020
@dstufft
Copy link
Contributor Author

dstufft commented Apr 5, 2020

I've manually tested this on Pytohn 2.7, 3.8, and 3.8 when running with certifi being zipimported.

Copy link
Member

@Lukasa Lukasa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @dstufft

@Lukasa Lukasa merged commit 3fc8fec into certifi:master Apr 6, 2020
@indygreg
Copy link

indygreg commented May 5, 2020

Are there any plans to make a new release of certify with this change?

@Lukasa
Copy link
Member

Lukasa commented Jun 7, 2020

Done.

tsibley added a commit to tsibley/python-certifi that referenced this pull request Sep 13, 2022
…n ≥3.11

Using importlib.resource's files() API on 3.9 and 3.10 causes a
TypeError on 3.9 and a ValueError on 3.10 when running under a
third-party meta path importer (like PyOxidizer's OxidizedImporter) that
doesn't support the relatively-new API.  This is because the full
adapter layer (importlib.resources._adapters) for the older importlib
resources API doesn't exist until Python 3.11.

The older resources API is now used by 3.7–3.10, as it was prior to the
certifi 2022.06.15.1 release.  This codepath has existed in certifi
since April 2020 (3fc8fec).

An alternative to this change would be testing the actual importer in
use at runtime (e.g. certifi.__loader__) for files() support, but that
seemed more complex than reverting to the previous codepath here.

Resolves: certifi#203
Related-to: certifi#199
Related-to: certifi#123
Lukasa pushed a commit that referenced this pull request Sep 13, 2022
…n ≥3.11 (#204)

Using importlib.resource's files() API on 3.9 and 3.10 causes a
TypeError on 3.9 and a ValueError on 3.10 when running under a
third-party meta path importer (like PyOxidizer's OxidizedImporter) that
doesn't support the relatively-new API.  This is because the full
adapter layer (importlib.resources._adapters) for the older importlib
resources API doesn't exist until Python 3.11.

The older resources API is now used by 3.7–3.10, as it was prior to the
certifi 2022.06.15.1 release.  This codepath has existed in certifi
since April 2020 (3fc8fec).

An alternative to this change would be testing the actual importer in
use at runtime (e.g. certifi.__loader__) for files() support, but that
seemed more complex than reverting to the previous codepath here.

Resolves: #203
Related-to: #199
Related-to: #123
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants