4 ms·

> In order to improve the experience for RHEL 8 users, we have moved the Python used by the system “off to the side” This was a good move. > we came to the to

> In order to improve the experience for RHEL 8 users, we have moved the Python used by the system “off to the side” This was a good move. > we came to the tough conclusion, don’t provide a default, unversioned Python at all. Ideally, people will get used to explicitly typing python3 or python2. This seems like a principled stance, one I can agree with. But it's probably one RHEL will suffer for. I think they have a lot of share for the enterprise linux marketplace (maybe #1 or #2?), so maybe they can afford it. RHEL customers should dust off their Python2 source and seriously consider migrating to straddle both 2 and 3 for now. Although the fact that RHEL8 provides ten years of Python 2 support means that they're unlikely to feel that pressure any time soon.

mkesper 8y ago
The whole eco system stops caring about Python2. Everybody using Python will suffer if they rely on using Python2 until 2030.
- rleigh 8y ago
  Unfortunately though, the whole ecosystem hasn't stopped caring, and is unlikely to anytime soon. They should care, but they either don't care or can't migrate quickly enough. Migration can be phenomenally expensive and introduce a ton of bugs. Python 2 will be the IE6 of this era. It's too entrenched to abandon. On the other hand, it will slowly fade into obscurity as migrations occur and old projects die. This approach is a fair one, which will keep all their customers happy. If you've got complex Python 2 applications deployed on CentOS 7, then this won't be a hindrance to migration. Likewise if you want to drop Python 2 and only deploy with Python 3, they have that covered as well. All in all, it sounds pragmatic and reasonable, and from the business point of view, they aren't going to lose customers as a result, by having huge blockers to upgrading.
mistrial9 8y ago
> customers should dust off their Python2 source Customers will do what they want to do with Python 2.7 code and libraries that work very well right now. The continuous improvement workers are clearly annoyed that Python 2.7 is not broken. With the right amount of effort, Python 2.7 will continue to work well for the next ten years. Perl comes to mind here..
- 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.
maxerickson 8y ago
Why would application developers try to straddle 2 and 3? If they are gonna do the work to support 3, just abandon 2. Libraries are a different story.
- rleigh 8y ago
  Usually it's because big projects are a logistical nightmare to migrate. You can't do it in one go. Not only do you have to transition every library plus the applications and tools and tests, you also have to keep it functional, testable and deployable on all the existing python 2 platforms as well. I'm not saying this is a good way of doing things, simply that it's the practical reality for many codebases. And with tools like python-modernise, it's also eminently achievable. I've managed to do this with several Python codebases, so that they work with either 2 or 3, and in the future we can drop 2 and fully migrate to 3-only features. This allows a smooth, seamless transition with no breakage. It would definitely be easier if a clean break could be made, and Python 2 support is dropped on the floor, but for many projects this is simply unacceptable.
fragmede 8y ago
> In order to improve the experience ... > yum install python results in a 404. I'm not convinced the attention is focused on "the experience". Returning 404 is hardly a user friendly experience, even if the linked blog post (and thus the solution) is trivially Googleable. Maybe an error/informational message with instructions to `yum install python3` or `yum install python2` could be displayed instead?
nine_k 8y ago
Yes, yes, and yes. The rule of (sore) thumb is: never use system Python for anything. Pretend it does not exist (and RH just did). It's there for running system software that happens to use Python interpreter and packages. It should only be managed by the system package / dependency manager. For anything you write or download as source, explicitly install the right Python version, and create a separate virtualenv / container / whatnot, without any link to system-provided Python packages. It will save you a huge amount of headache.

mkesper 8y ago

The whole eco system stops caring about Python2. Everybody using Python will suffer if they rely on using Python2 until 2030.

rleigh 8y ago
Unfortunately though, the whole ecosystem hasn't stopped caring, and is unlikely to anytime soon. They should care, but they either don't care or can't migrate quickly enough. Migration can be phenomenally expensive and introduce a ton of bugs. Python 2 will be the IE6 of this era. It's too entrenched to abandon. On the other hand, it will slowly fade into obscurity as migrations occur and old projects die. This approach is a fair one, which will keep all their customers happy. If you've got complex Python 2 applications deployed on CentOS 7, then this won't be a hindrance to migration. Likewise if you want to drop Python 2 and only deploy with Python 3, they have that covered as well. All in all, it sounds pragmatic and reasonable, and from the business point of view, they aren't going to lose customers as a result, by having huge blockers to upgrading.

mistrial9 8y ago

> customers should dust off their Python2 source Customers will do what they want to do with Python 2.7 code and libraries that work very well right now. The continuous improvement workers are clearly annoyed that Python 2.7 is not broken. With the right amount of effort, Python 2.7 will continue to work well for the next ten years. Perl comes to mind here..

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.

maxerickson 8y ago

Why would application developers try to straddle 2 and 3? If they are gonna do the work to support 3, just abandon 2. Libraries are a different story.

rleigh 8y ago
Usually it's because big projects are a logistical nightmare to migrate. You can't do it in one go. Not only do you have to transition every library plus the applications and tools and tests, you also have to keep it functional, testable and deployable on all the existing python 2 platforms as well. I'm not saying this is a good way of doing things, simply that it's the practical reality for many codebases. And with tools like python-modernise, it's also eminently achievable. I've managed to do this with several Python codebases, so that they work with either 2 or 3, and in the future we can drop 2 and fully migrate to 3-only features. This allows a smooth, seamless transition with no breakage. It would definitely be easier if a clean break could be made, and Python 2 support is dropped on the floor, but for many projects this is simply unacceptable.

fragmede 8y ago

> In order to improve the experience ... > yum install python results in a 404. I'm not convinced the attention is focused on "the experience". Returning 404 is hardly a user friendly experience, even if the linked blog post (and thus the solution) is trivially Googleable. Maybe an error/informational message with instructions to `yum install python3` or `yum install python2` could be displayed instead?

nine_k 8y ago

Yes, yes, and yes. The rule of (sore) thumb is: never use system Python for anything. Pretend it does not exist (and RH just did). It's there for running system software that happens to use Python interpreter and packages. It should only be managed by the system package / dependency manager. For anything you write or download as source, explicitly install the right Python version, and create a separate virtualenv / container / whatnot, without any link to system-provided Python packages. It will save you a huge amount of headache.