Live data from Hacker News

What, No Python in RHEL 8 Beta?

developers.redhat.com

31–40 of 63 posts

Re: What, No Python in RHEL 8 Beta?

#31
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?

Red Hat-specific tools or just all the general system utilities nstalled on a RHEL host? I've got a ThinkPad sitting here running the beta of RHEL 8. (FWIW, I don't think either is installed by default, but maybe that was something else I installed recently?)

Neither ship by default. If you run a search for libpython you should find one hidden away in a nonstandard location. As far as I’m aware, only core tools necessary for a minimal install rely on it. Other packages in the repos can depend on an actual user space python version.

^ Needs verification

Re: What, No Python in RHEL 8 Beta?

#32

Earlier quoted context omitted.

Note: You shouldn't use #!/usr/bin/env python. Instead you should explicitly specify python2 or python3, unless your script is compatible with both.

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…

Of the 50 /usr/bin/ python files on my Ubuntu 16.04 desktop, most are versioned in some way. None are called from "env".

     37 /usr/bin/python3
      4 /usr/bin/python3.5
      4 /usr/bin/python
      3 /usr/bin/python2.7
      2 /usr/bin/python2
The 4 that aren't versioned are

speedtest, speedtest-cli, dh_python2, apt-offline

So two from ubuntu/debian, and two from a package

Re: What, No Python in RHEL 8 Beta?

#33

Earlier quoted context omitted.

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.

Thats not really fair. Python 3.2 was release in 2011 and Python 3.4 in 2014. Only 3.3 was released in the middle, I would not say it is only "so often" compared to c++. To be more general, C++ had 3 major versions from 2011 to 2017, while python had 5. Its more, but not significantly so (especially since very little compatibility is broken between 3.4 and 3.5 for example). And if you are talking about which version…

But the compiler is the same, so you specify the dialect you expect to use rather than running a different binary. Although to be fair, at least one distro decided to start shipping gcc like gcc-X where X is the version, so you can have multiple GCC's installed. I'm not sure that was the best idea, but its what they did.

Re: What, No Python in RHEL 8 Beta?

#34

Earlier quoted context omitted.

Note: You shouldn't use #!/usr/bin/env python. Instead you should explicitly specify python2 or python3, unless your script is compatible with both.

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 root, `yum` breaks and it's hard to recover the system.

What the article is saying is that RHEL 8 addresses this by having a platform python that the system tools use. So RHEL 8 tools will not use /usr/bin/python

Re: What, No Python in RHEL 8 Beta?

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

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

Re: What, No Python in RHEL 8 Beta?

#36
Great move. I recently experienced the whole Ubuntu 16.04 LTS Python 3.5 and 3.6 on my system and it is just plain messy. Yeah, they can co-exist, but now I have 3 versions of Python. How many people didn't know better and have have tried removing 3.5 and completely broke their install and possibly ruined their weekend or evening. It also sends a message. A proper / official way for distributions to deal with this situation is needed.

Re: What, No Python in RHEL 8 Beta?

#37
post #29
post #26

Earlier quoted context omitted.

Install instructions are right at the top and are typical `yum` commands that RHEL users should already know.

So RHEL been around for 18 years, and suddendly users need to be aware about the "install instructions", which "are right at the top" and read a blog post about it for RHEL 8?

Presumably with RHEL being around for 18 years users would be able to run "yum search python", see the packages are versioned, and yum install the version they want. All sans blog article.

It's far from the first time in 18 years a package name has changed with a major version upgrade.

Re: What, No Python in RHEL 8 Beta?

#38
post #10

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.

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?

Re: What, No Python in RHEL 8 Beta?

#39
post #5

Earlier quoted context omitted.

Wouldn't you just specify the dependencies in your installer so it just works?

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?

Re: What, No Python in RHEL 8 Beta?

#40
post #15

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.

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…

Doesn't Python 3 compile the .pyc files under the __pycache__ directory, and version them based on Python's version?
Post reply on HN