Matthias Bussonnier, Min Ragan-Kelley, M Pacer, Thomas Kluyver - Ending Py2/Py3 compatibility in a user friendly manner

Matthias Bussonnier, Min Ragan-Kelley, M Pacer, Thomas Kluyver - Ending Py2/Py3 compatibility in a user friendly manner

> "Four shalt thou not count, neither count thou two, excepting that thou
then proceed to three."

>> Monty Python and the Holy Grail; Scene 33

Python 3 has been around for more than eight years, and much of the Python
ecosystem is now available both on Python 2 and Python 3, often using a single
code base. Nonetheless, this compatibility comes at a development cost and some
library authors are considering ending support for Python 2 . These
once-python-2-compatible libraries are at risk of being upgraded on non
compatible system and cause user (and developer) frustration.

While it may seem simple to cease support for Python 2, the challenge is not in
ending support, but doing so in a way that does not wreak havoc for users who
stay on Python 2. And that is not only a communications problem, but a
technical one : up until recently, it was impossible to tag a release as Python
3 only; today it is possible.

Like any maintainer of a widely used library, we want to ensure that users
continue to use Python 2 continue to have functioning libraries, even after
development proceeds in a way that does not support Python 2.

One approach is to ensure easy installation of older versions if possible avoid
incompatible versions altogether. Users should not need to manually pin maximal
version dependencies across their development environments and projects if all
they want is to use the latest versions of libraries that are compatible with
their system.

Even if we did expect that of users, consider what would happen when a package
they rely on converts to be only Python 3 compatible. If they were not tracking
the complete dependency tree, they might discover, on upgrade, that their
projects no longer work. To avert this they would need to pin those at the last
version compatible with Python 2. Users that want to use older python versions
should not have to go through so much anguish to do so.

In order to solve this problem, and thereby make both users' and maintainers'
lives easier, we ventured into the rabbit-hole called Packaging.

Though we set off with a singular quest, our tale roves through many lands.
We'll narrate the story of our amending PEPs, our efforts in building the
ramparts of the pypa/Warehouse Castle, battles with the dragons of Pip, and
errands in the "land of no unit tests" otherwise known as PyPI legacy.

By the end of the above tale, the audience members will know the road to Python
3 only libraries had once had hazards that are now easily avoidable. So long as
users upgrade their package management tools.


PyCon 2017

May 21, 2017