Consider URLLib3Transport interface, since it's becoming public API. #966

Activity

1. lovelydinosaur

   added this to the v0.13 milestone on May 21, 2020
2. lovelydinosaur commented on May 21, 2020

   

   lovelydinosaur

   on May 21, 2020

   Last edited by lovelydinosaur

   MemberAuthor

   More actions

   Also we could just drop the URLLib3Dispatch compat shim, since it's only ever existed in the pre-releases.

   And in any case, never made it to the public interface even then.

   👍React with 👍1Reacted by Florimond Manca
3. florimondmanca commented on May 21, 2020

   

   florimondmanca

   on May 21, 2020

   Last edited by florimondmanca

   Contributor

   More actions

   The only reason I'd be in favor of keeping URLLib3Transport is to make it easier for folks that use Requests to migrate over without having to deal with slight behavior differences right away.

   I'm actually not certain that's what people would do in practice - there are already lots of behavior differences that come from switching from Requests anyway, so not sure if switching to our transport is a big leap.

   Another argument in favor of dropping it before 1.0 lands would be reducing maintenance burden - now that the transport interface is public it would be pretty easy for someone to maintain this as a 3rd party component (esp given that we have a working implementation in 0.12.x for people to take inspiration from). But at the same time, it's not very high cost.

   Edit: oh okay, I didn't get that you were talking about the Transport/Dispatch compatibility layer. Sure, let's drop it IMO. I guess what I wrote above^ is another discussion then. 😄

   👍React with 👍1Reacted by Yeray Díaz
4. yeraydiazdiaz commented on May 21, 2020

   

   yeraydiazdiaz

   on May 21, 2020

   Contributor

   More actions

   I'm 👍 on dropping URLLib3Transport completely tbh.

   I might be missing something but it seems atm it feels like the remnants of our old sync flow rather than a core piece of HTTPX that users would reach for. It already has our lowest test coverage percentage, feels like it will eventually break for someone since it's now in the public API.
5. lovelydinosaur commented on May 21, 2020

   

   lovelydinosaur

   on May 21, 2020

   MemberAuthor

   More actions

   Okay, well let's drop the URLLib3Transport/URLLib3ProxyTransport convo from the 0.13 milestone so we can get this thing released, and keep the idea of URLLib3Transport as a third-party-package as an open option.

   (Personally I probably think it's a pretty useful thing to have available to us, but I'm not absolute on it.)

   👍React with 👍1Reacted by Florimond Manca
6. lovelydinosaur

   modified the milestones: v0.13, v1.0 on May 21, 2020
7. lovelydinosaur commented on May 21, 2020

   

   lovelydinosaur

   on May 21, 2020

   MemberAuthor

   More actions

   Remaining points for 1.0 consideration...

   • Do we want URLLib3Transport/URLLib3ProxyTransport for consistency with httpcore interface, and urllib3's PoolManager/ProxyManager?
   • Do we want to drop URLLib3Transport into a third party package instead?
8. lovelydinosaur commented on Jul 25, 2020

   

   lovelydinosaur

   on Jul 25, 2020

   MemberAuthor

   More actions

   We can close this off now.

   Once #1090 is addressed, the signatures are...

   class URLLib3Transport(httpcore.SyncHTTPTransport):
       def __init__(
           self,
           *,
           verify: VerifyTypes = True,
           cert: CertTypes = None,
           trust_env: bool = None,
           pool_connections: int = 10,
           pool_maxsize: int = 10,
           pool_block: bool = False,
       ):

   And...

   class URLLib3ProxyTransport(URLLib3Transport):
       def __init__(
           self,
           *,
           proxy_url: str,
           proxy_headers: dict = None,
           verify: VerifyTypes = True,
           cert: CertTypes = None,
           trust_env: bool = None,
           pool_connections: int = 10,
           pool_maxsize: int = 10,
           pool_block: bool = False,
       ):
9. lovelydinosaur

   closed this as completedon Jul 25, 2020