What, No Python in RHEL 8 Beta? • Hacker News Board

Re: What, No Python in RHEL 8 Beta?

#41

Post by throwaway98434 » Wed, Dec 19, 2018, 5:43 PM UTC

rterzi wrote: post #34

throwaway98434 wrote: post #28

Earlier quoted context omitted.

You say "you" as if you're talking to the person you're replying to. Most scripts in the world aren't authored by the person you're replying to. They're powerless to change the ocean of python out in the world. 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 short…

First, This is about RHEL 8 (Beta) not 7, 6, etc. Second `#!/usr/bin/python` is a different animal than `#!/usr/bin/env python`. One is hard coded. The other is `PATH` based so will change depending on current `PATH`. On RHEL 7 (and earlier) `/usr/bin/python` must be the Python 2 the system shipped with or your break `yum` and other admin tools. When people try to install their own python by doing a `make install` as…

CoolGuySteve complained that things will break because existing scripts assume /usr/bin/python. CoolGuySteve is correct. There is an enormous amount of work involved in changing or removing the function of /usr/bin/python.

Offering advice about how to write new software does nothing to help with the frustration he highlighted: His existing build systems will break. Build systems are especially frustrating as they tend to have hacked-together code that no one really wants to look at.

People will often work around this by installing a python2 as /usr/bin/python. At the end of the day this change results in a less predictable platform. On previous RHEL systems I know what /usr/bin/foo is -- it's predictable given the major version of the distro. But now I won't know what /usr/bin/python is on RHEL8. It will be uniquely different and that's not a good thing.

Re: What, No Python in RHEL 8 Beta?

#42

Post by nine_k » Wed, Dec 19, 2018, 5:46 PM UTC

wyldfire wrote: post #2

> 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…

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.

Re: What, No Python in RHEL 8 Beta?

#43

Post by Spivak » Wed, Dec 19, 2018, 5:47 PM UTC

mroche wrote: post #38

Spivak wrote: post #10

Earlier quoted context omitted.

Which is fine but how do you specify dependencies right now? Surely a minimal install of RHEL doesn't have everything you need.

Not meant to be snarky, just a tad confused on what exactly you’re asking. Have you ever made an RPM yourself? Dependencies are specified there. Or are you asking about dependencies that don’t exist in standard RHEL repositories?

The parent was saying that specifying dependencies with rpm wasn't possible because they deploy with git but surely they must have something to specify/install deps since a RHEL base likely doesn't have everything they need especially if they're using the system python.

Re: What, No Python in RHEL 8 Beta?

#44

Post by rterzi » Wed, Dec 19, 2018, 5:49 PM UTC

dralley wrote: post #17

nailer wrote: post #11

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?

Fedora doesn't ship with any Python 2, all the utilities in the default installation are Python 3.

"Ship with" is a bit too ambiguous for my taste. F28/F29 "ship with" Python 2 in the sense that the packages are there, just not installed with a default install. If you `dnf install python2` (or something that depends on Python 2.7) it will get installed. They've also gone through the effort and moved the system stuff line dnf to Python 3.

Re: What, No Python in RHEL 8 Beta?

#45

Post by rterzi » Wed, Dec 19, 2018, 5:51 PM UTC

solarkraft wrote: post #39

CoolGuySteve wrote: post #7

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.

Can't you just symlink your preferred python?

No need to symlink manually, the `alternatives` mechanism will handle that for you.

Re: What, No Python in RHEL 8 Beta?

#46

Post by rleigh » Wed, Dec 19, 2018, 5:55 PM UTC

maxerickson wrote: post #30

wyldfire wrote: post #2

> 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…

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.

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.

Re: What, No Python in RHEL 8 Beta?

#47

Post by wyldfire » Wed, Dec 19, 2018, 6:03 PM UTC

School-Cotton wrote: post #19

hedora wrote: post #15

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.

> Maybe Python should stop changing so often?

This argument is almost cyclical.

> 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.

C++ went from glacial-pace changes - 85 / 98 / 03 / 11 -- to much faster ones: 14, 17, 20. This change in standards behavior was motivated by closing the gap with feature-rich, faster-moving languages like Python (Java, C#, etc).

Python makes language changes somewhat rarely, but library changes more often. The majority of the time, those library changes are brand new functionality.

Re: What, No Python in RHEL 8 Beta?

#48

Post by rleigh » Wed, Dec 19, 2018, 6:04 PM UTC

mistrial9 wrote: post #23

wyldfire wrote: post #2

> 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 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..

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.

Re: What, No Python in RHEL 8 Beta?

#49

Post by mroche » Wed, Dec 19, 2018, 6:10 PM UTC

Spivak wrote: post #43

mroche wrote: post #38

Earlier quoted context omitted.

Not meant to be snarky, just a tad confused on what exactly you’re asking. Have you ever made an RPM yourself? Dependencies are specified there. Or are you asking about dependencies that don’t exist in standard RHEL repositories?

The parent was saying that specifying dependencies with rpm wasn't possible because they deploy with git but surely they must have something to specify/install deps since a RHEL base likely doesn't have everything they need especially if they're using the system python.

I think at that point we’re kind of stuck with virtual environments for Python dependencies. I’m not too sure what the best solution is.

Re: What, No Python in RHEL 8 Beta?

#50

Post by nrclark » Wed, Dec 19, 2018, 6:13 PM UTC

KerrickStaley wrote: post #12

CoolGuySteve wrote: post #7

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.

Totally agree in principle.

One interesting note - MacOS doesn't have a /usr/bin/python2 (at least, not at the time of this writing). It supplies /usr/bin/python, and also /usr/bin/python2.7.

That might not matter at all, but it's worth noting.