> On Jun 5, 2017, at 7:00 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 5 June 2017 at 18:42, Cory Benfield <c...@lukasa.co.uk > <mailto:c...@lukasa.co.uk>> wrote: >> On 3 Jun 2017, at 07:25, Nick Coghlan <ncogh...@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? >
Is pip allowed to use the hypothetical _ensurepip_ssl outside of ensurepip? Thinking about this reminded me about the *other* reason pip avoids dependencies— avoiding making assertions about what versions of software can actually be installed. IOW if pip depends on pyOpenSSL >= X.Y, then you essentially can’t install any other version of pyOpenSSL and you’d be forced to upgrade. This isn’t end of the world and pyOpenSSL is generally stable enough we could *probably* get away with a unversioned dependency on a non Windows platform. On Windows we’d have to uh, I guess use a SChannel c-types backend? Not having our TLS library in the stdlib makes it a bit more difficult, but from pip’s own POV if there’s a MemoryBio that we’re allowed to use and then requests uses pyOpenSSL normally (we’d apply a small patch to pip’s copy of requests to make it use it, but that’s easy to do with our setup) I think that would be workable. I think that’s a less optimal solution than just accepting PEP 546 which I think is beneficial to the Python ecosystem as a whole, making it easier to port more code onto 3.x (and allowing unlocking 3.x’s capabilities) and will make it easier to maintain the ssl library on 2.7, given it will have less of a divergence from 3.x again. — Donald Stufft
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
