[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

[Nick Coghlan]

On 5 June 2017 at 18:42, Cory Benfield <cory at lukasa.co.uk> wrote:
> On 3 Jun 2017, at 07:25, Nick Coghlan <ncoghlan at gmail.com> wrote:
> As a result, as awkward and annoying as it would be, I'm wondering if
> the structure of the requests migration may need to be something like:
>
> - switch unconditionally to an async backend on Py3
> - switch conditionally to an async backend on Py2 when PyOpenSSL is
> available
> - retain sufficient sync-only support on Py2 to allow pip to disable
> the PyOpenSSL dependency
>
> Ultimately we don’t have the resources to do this.
>
> The requests core development team is 4 people, 3 of whom are part time
> best-effort maintainers and one of whom is me, who has foolishly decided to
> also work on PEP 543 as well as take over the lead maintenance role on
> urllib3. urllib3 has another two additional best-effort maintainers.
>
> We simply do not have the development resources to support two parallel
> branches of code. Even if we did, doing so is a recipe for adding bugs and
> inconsistencies between the two, leading to increased workload as we break
> our users and fail to keep the two branches in sync. It also makes it much
> harder for users to migrate from our synchronous backend to our async one,
> as those two no longer use identical underlying implementations and so will
> have subtle inconsistencies.
>
> The TL;DR there is: no, we’d rather stay sync only than do that.

Would you be OK with the notion of a "just for pip bootstrapping"
private backend in _ensurepip_ssl?

That is, the only officially supported async-backed requests
configuration on Py2 would be with the PyOpenSSL dependency installed,
but in collaboration with the pip devs we'd also plumb in the pieces
to let a new async-backed requests work without any extension modules
other than those in the standard library.

That way, the only thing truly gated on the backport would be *pip*
updating its bundled version of requests to the async-backed version -
for normal third party use, the change would be "you need PyOpenSSL",
rather than "you need a newer version of Python".

We'd still effectively end up with two different code execution paths
(one backed by PyOpenSSL, one backed by the new private _ensurepip_ssl
extension module), but the level of divergence would be much lower
(it's just a question of where MemoryBIO and SSLObject are coming
from) and the support scope for the less frequently used path would be
much narrower (i.e. if a problem report isn't related to pip
bootstrapping, it can be closed as "won't fix")

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia