urllib3 2.0 and Python 3.12

David Gilman davidgilman1 at gmail.com
Fri Oct 6 14:23:54 UTC 2023


urllib3 2.0 has substantial API changes. It is not impossible to do
this update in MacPorts but there are a lot of dependent packages and
the migration runs the risk of getting blocked on a single package
whose upstream is not making timely releases. It's the typical
dependency story we have in MacPorts when you try to update a popular,
fundamental dependency, complicated by the urllib3 upstream not
willing to change their import name with this release. [1]

Upstream also dropped pre-Python 3.7 support in 2.x and plans on
dropping 3.7 support in the 2.1 release. The 1.x branch is also on
some deprecated APIs that will be dropped in 3.14. Going forward this
is going to frustrate MacPorts compatibility with old Pythons.

As an alternative to the usual flag day upgrade process across all of
Python 3.7+ at the same time, how does this alternative sound: take
advantage of the newly released Python 3.12 and *only* release urllib3
2.0 under the py312-urllib3 subport. As dependent ports add their own
py312- subports their maintainer has the opportunity to check for
urllib3 2.0 compatibility at the dependent port's leisure.

This is not how we typically do things in MacPorts but it does not
seem like an awful compromise. It is a natural way to prevent API
conflicts with urllib3 2.0: simply don't publish a py312- subport
until you have urllib3 2.0 support. Old, abandoned ports and packages
likely won't get a py312- subport and never have to consider urllib3
2.0 compatibility and nobody spends any brain cycles on assessing
their compatibility with urllib3 2.0.

[1] If you look on pypi you can see that urllib4 and urllib5 are
taken, maybe it was too much to ask to go directly from urllib3 to
urllib6.

-- 
David Gilman
:DG<


More information about the macports-dev mailing list