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 provider loading take two #10390

Merged
merged 1 commit into from Feb 15, 2024
Merged

fix provider loading take two #10390

merged 1 commit into from Feb 15, 2024

Conversation

reaperhulk
Copy link
Member

we previously hoisted this into rust, but we used the try_load feature which supposedly retains fallbacks. Something about that doesn't behave the way we expect though and the machinery in providers is sufficiently complex that we are just going to load the default provider explicitly.

this matches our behavior pre-rust.

hopefully fixes #10389

alex
alex previously approved these changes Feb 13, 2024
@alex alex enabled auto-merge (squash) February 13, 2024 22:43
we previously hoisted this into rust, but we used the try_load feature
which supposedly retains fallbacks. Something about that doesn't behave
the way we expect though and the machinery in providers is sufficiently
complex that we are just going to load the default provider explicitly.

this matches our behavior pre-rust.
@alex alex merged commit 64b9095 into pyca:main Feb 15, 2024
57 checks passed
@reaperhulk reaperhulk deleted the manual-load branch February 16, 2024 02:52
reaperhulk added a commit to reaperhulk/cryptography that referenced this pull request Feb 16, 2024
we previously hoisted this into rust, but we used the try_load feature
which supposedly retains fallbacks. Something about that doesn't behave
the way we expect though and the machinery in providers is sufficiently
complex that we are just going to load the default provider explicitly.

this matches our behavior pre-rust.
alex pushed a commit that referenced this pull request Feb 16, 2024
we previously hoisted this into rust, but we used the try_load feature
which supposedly retains fallbacks. Something about that doesn't behave
the way we expect though and the machinery in providers is sufficiently
complex that we are just going to load the default provider explicitly.

this matches our behavior pre-rust.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Loading EC key with 42.0.2 fails first time, then succeeds every time after
2 participants