3 ms·

It's going to break horribly in 2020 irrespective of RedHat's efforts. Earlier this year, one of the projects I maintained started failing on CentOS 6 (Python

by rleigh 8y ago

It's going to break horribly in 2020 irrespective of RedHat's efforts. Earlier this year, one of the projects I maintained started failing on CentOS 6 (Python 2.6). No code changes had been made to account for it. What had happened was that pip/pypi had updated some modules which had dropped Python 2.6 support, and now required Python 2.7. Unfortunately, the package management and dependency information is so rudimentary that pip will happily create an environment which is completely broken, or fails to build due to the scripts being incapable of running with an older interpreter. This completely broke our build. The same fate lies in wait for Python 2.7. A number of common modules are planning on fully dropping Python 2.7 support come the EOL date. Once they do so, pip will break, and it will not be possible to construct a working environment except by hand. Or using manually packaged modules e.g. from the FreeBSD ports tree or the Debian archive. This will be the death knell for Python 2.7 for practical use and deployment. It will only take a tiny number of critical modules to make the switch for the whole pip/pypi ecosystem to be completely crippled for use with Python 2.7.

vetinari 8y ago
> Once they do so, pip will break, and it will not be possible to construct a working environment except by hand. Or using manually packaged modules e.g. from the FreeBSD ports tree or the Debian archive. Or by explicitly specifying versions in requirements.txt (yes, it can be pita for dependencies inherited from other packages). Pypi does keep the old versions, no need to scour fbsd or debian archives.
- rleigh 8y ago
  Yes, you're absolutely right about requirements.txt. However as you say, it's a problem when you have to start considering transitive dependencies. In fact, for the case I mentioned, this became a problem because there were so many it became increasingly complex; you ended up having to start moving more and more of the transitive dependencies directly into the requirements file. And this isn't very scalable. That on its own would be somewhat manageable. But if you start getting requirements to update "just one more module" for some specific functionality, you eventually end up at the point where it's not possible to provision a functional set of modules. That's where I ended up with 2.6, and 2.7 is likely to be just the same, in my opinion.
  - vetinari 8y ago
    Transitive dependencies (or what I called inherited from other packages) can be solved with pip freeze in existing working environment; it will list them too. New development, on the other hand, will be difficult. As it usually is, when you develop in something that has been obsoleted years ago. If you are still developing the system, instead of just keeping it running, shouldn't you spend some resources on python3 migration, too? The modules you need are already there.
    - rleigh 8y ago
      No disagreement here from me! The times we have had to update things have been when the existing modules broke. One example which comes to mind from the recent past is when urllib TLS certificate stuff broke and it needed updating. In that case, it didn't cause collateral damage, but we were forced to do it to keep things working. Externally-enforced changes like this could potentially cause breakage in the future if they drop python 2.7 support directly or indirectly.

by rleigh 8y ago

vetinari 8y ago

> Once they do so, pip will break, and it will not be possible to construct a working environment except by hand. Or using manually packaged modules e.g. from the FreeBSD ports tree or the Debian archive. Or by explicitly specifying versions in requirements.txt (yes, it can be pita for dependencies inherited from other packages). Pypi does keep the old versions, no need to scour fbsd or debian archives.

rleigh 8y ago
Yes, you're absolutely right about requirements.txt. However as you say, it's a problem when you have to start considering transitive dependencies. In fact, for the case I mentioned, this became a problem because there were so many it became increasingly complex; you ended up having to start moving more and more of the transitive dependencies directly into the requirements file. And this isn't very scalable. That on its own would be somewhat manageable. But if you start getting requirements to update "just one more module" for some specific functionality, you eventually end up at the point where it's not possible to provision a functional set of modules. That's where I ended up with 2.6, and 2.7 is likely to be just the same, in my opinion.
- vetinari 8y ago
  Transitive dependencies (or what I called inherited from other packages) can be solved with pip freeze in existing working environment; it will list them too. New development, on the other hand, will be difficult. As it usually is, when you develop in something that has been obsoleted years ago. If you are still developing the system, instead of just keeping it running, shouldn't you spend some resources on python3 migration, too? The modules you need are already there.
  - rleigh 8y ago
    No disagreement here from me! The times we have had to update things have been when the existing modules broke. One example which comes to mind from the recent past is when urllib TLS certificate stuff broke and it needed updating. In that case, it didn't cause collateral damage, but we were forced to do it to keep things working. Externally-enforced changes like this could potentially cause breakage in the future if they drop python 2.7 support directly or indirectly.