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<
