21–30 of 63 posts
Any current Fedora users want to tell me what all the Red Hat tools use? Eg is usr bin banana actually Python 2 or Python 3?
(FWIW, I don't think either is installed by default, but maybe that was something else I installed recently?)
This is such a strange and annoying compromise to make. It's somewhat antithetical to the concept of RHEL versions being a standardized set of packages such that when someone says "I have RHEL 7", you can say "My software will work on that". Now in order to support RHEL 8, you have to tell them to also have their sys admin install your preferred python. A better and less bespoke to RHEL solution imo would have been t…
The best solution I am aware of is to package your Python apps statically with the version they expect. For example, Facebook's XAR format ( https://github.com/facebookincubator/xar/ ) does this very nicely.
> 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…
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..
Earlier quoted context omitted.
I’m pissed almost daily at how many build systems break because they need 3.5.3 vs 3.5.4 or whatever, and at how many only work because they create a new virtual environment for every single script (Virtual environment ~= copy of python auto-downloaded from some random places). Also, FFS, why can’t pyc files have a bytecode format version number embedded in them, or at least be called .pyc3 by python 3? The whole eco…
Maybe Python should stop changing so often? With C++ for example you are usually either targeting C++11, C++14, or C++17 (or if you're really unfortunate, C++03). The set of features in the language only changes every few years. Granted it's still possible that someone could have an old compiler that doesn't implement the advertised standard correctly, but that's a bug , not a deliberate design choice.
And if you are talking about which version is shipped with a distro, then RHEL7 ships with gcc 4.8, which support only parts of c++14, while for example the latest Ubuntu LTS ships GCC 7,3, meaning you get full C++17 support.
Don't get me wrong, the Python packaging situation is not very clean. But it is far from being an exception, and people complaining about it are just spreading FUD.
"However, we do try to make it as easy as possible to get Python 2 or 3 (or both) on to your system." - it just requires quite a long blog post to explain how easy it is.
> 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…
The whole eco system stops caring about Python2. Everybody using Python will suffer if they rely on using Python2 until 2030.
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.
Earlier quoted context omitted.
Most people in my field don't use installers or rpms, we just share the git repo directly. I'm kind of pissed off just thinking about how many build systems will break when '/usr/bin/env python' doesn't return anything by default.
Note: You shouldn't use #!/usr/bin/env python. Instead you should explicitly specify python2 or python3, unless your script is compatible with both.
For example, out of about 50 or so /usr/bin/python scripts I see in a RHEL7's /usr/bin I can't find a single one that runs on python3.
No individual user is going to be fixing this. It's a very silly and shortsighted move on RedHat's part.
"However, we do try to make it as easy as possible to get Python 2 or 3 (or both) on to your system." - it just requires quite a long blog post to explain how easy it is.
Install instructions are right at the top and are typical `yum` commands that RHEL users should already know.
> 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…
If they are gonna do the work to support 3, just abandon 2.
Libraries are a different story.