Live data from Hacker News

What, No Python in RHEL 8 Beta?

developers.redhat.com

11–20 of 63 posts

Re: What, No Python in RHEL 8 Beta?

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

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

Re: What, No Python in RHEL 8 Beta?

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

#!/usr/bin/env python is almost guaranteed to give you a surprise at some point. If someone has a virtualenv or conda env active in that shell it will be a different python environment (with different installed modules) than in other shells.

Re: What, No Python in RHEL 8 Beta?

#14
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 at least as of F28, moved to have system tools like dnf use Python 3.

For RHEL 8, the tools included with the system will use a different binary, platform-python that isn't in /usr/bin.

I can't remember if that's also the case for F28/F29.

Re: What, No Python in RHEL 8 Beta?

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

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 ecosystem needs to solve the packaging problem, or get replaced by some other language ASAP. Instead, it’s breaking entire distros with its packaging tire fire.

For many python projects I’ve dealt with, it is easier to reimplement that dang thing in some other language than make the python build reliable, secure and redistributable.

Re: What, No Python in RHEL 8 Beta?

#16
post #13

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.

#!/usr/bin/env python is almost guaranteed to give you a surprise at some point. If someone has a virtualenv or conda env active in that shell it will be a different python environment (with different installed modules) than in other shells.

At least in the build-system glue language use case, the 'batteries included' modules like os, sh, glob, etc will all be there.

Similarly, if you require pandas like I do, there's a fairly comprehensive baseline of functionality you can expect regardless of what environment it comes from.

Re: What, No Python in RHEL 8 Beta?

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

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.

Re: What, No Python in RHEL 8 Beta?

#20

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.
Post reply on HN