-
-
Notifications
You must be signed in to change notification settings - Fork 829
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
Add httpx.SSLContext
configuration.
#3022
base: master
Are you sure you want to change the base?
Add httpx.SSLContext
configuration.
#3022
Conversation
897a5de
to
88f2ab7
Compare
Removing |
Yes, I agree that removing them completely is not what the user expects. Or should we deprecate them anyway? Not obvious to me. |
There are dropping from top-level API, I think deprecation policy should be applied here. Also, we have other deprecated drops those pending to remove in v1.0.0 (IIUC):
|
Looking good.
I'd suggest you don't spin time on that until we've had a clear discussion around the "API finessing" and "Documentation refresh" areas mentioned in #947 (comment). I like this change, but we'll want to make it as part of a coherent & consistent 1.0 refresh. |
httpx.SSLContext
configuration.
Okay, shall we take the docs from this comment... #3007 (comment) and include them in the PR? |
I like it |
Have we decided to remove or deprecate the old arguments? |
deprecate warning on 0.27 This is what I can be happy with. |
Is there a reason we should continue to support the old API? As far as I can tell, the primary reason for deprecating is that we are adding new functionality and fixing bugs in applications that use the old API. |
My contextual reason got from https://astral.sh/blog/ruff-v0.2.0
Actually, those releases are for users using version pinning ( |
Actually, we are very close to HTTPX 1.0, so I believe there will be just 1-2 releases before then, in which we would primarily introduce the new API, so there will be no features that we would want to ship to our users who are still using the old API. Also, this migration is rather easy, and I don't believe we need to complicate this PR. Client configurations are frequently found in 1-2 places across the source code, therefore let's make this PR concise and avoid dealing with both new and old APIs. |
Then, we can merge this PR for v1.0 but not 0.27. (breaking api)
The error could describe the reason for the drop. This could be removed sometimes later. |
Yep, that's what we'll do.
We might choose not to handle the error cases for this: it requires leaving dead code across a lot of function calls. |
Related... #3126 |
Looks wonderful... some conflicts that need resolving, other than that I think we ought to get this merged. |
Do we have any blockers here? |
Just a changelog entry I think? And then we figure out what we want to do version-wise. |
Seems like we should merge this directly into 1.0 because we do have breaking changes here. |
Hi @karpetrosyan - apologies for the delay. (We may also want to follow this up with an issue for having a single global default) |
Discussed in #3007
TODO:
Migration examples
Enabling and disabling verification
Use a different set of certificates
Client side certificates
Using alternate SSL contexts