Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What, No Python in RHEL 8 Beta?

developers.redhat.com

Post reply on HN
Print view View original

51–60 of 63 posts

Re: What, No Python in RHEL 8 Beta?

#51

Post by moosingin3space »

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?

On Fedora, there's a system Python interpreter installed at `/usr/libexec/system-python` that is used to run Python tools installed in the base system like `dnf`. On my F29 system, it's version 3.7. You can't install pip packages into the system Python environment, which helps you not break your system, like what can happen if you've ever run `sudo pip install --upgrade pip` on Ubuntu or Debian!

Re: What, No Python in RHEL 8 Beta?

#52

Post by vetinari »

rleigh wrote: post #48
mistrial9 wrote: post #23

Earlier quoted context omitted.

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

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

Re: What, No Python in RHEL 8 Beta?

#53

Post by rleigh »

vetinari wrote: post #52
rleigh wrote: post #48

Earlier quoted context omitted.

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

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

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.

Re: What, No Python in RHEL 8 Beta?

#54

Post by throwaway98434 »

isostatic wrote: post #32
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…

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

Right, someone working in ubuntu distro development has done this work for those packages specifically.

Above, we're discussing some build system where someone hasn't done this work. Most collections of python code in the world (I'm going to hazard a guess significantly upward of 90%) just use /usr/bin/python or /usr/bin/env python.

That's the nature of the problem.

Re: What, No Python in RHEL 8 Beta?

#55

Post by nitroll »

swalsh wrote: post #8

I recently installed OpenSuse tubleweed. I'm not sure if I just had a weird installation, but both python 2.7, and python 3.6 were installed. That's great, but the "pip" command by default was pointed at pip3.6. Imagine how confused I was when I installed a bunch of packages using the "pip" command, but none of them were available from the default "python" shell. I think the, let's be explicit about what we're instal…

python3 -m pip install foo

It also works for python2. I try to avoid using python tools that installs their own scripts and go for calling the module through python. This also works for python3/2 -m venv venv

Re: What, No Python in RHEL 8 Beta?

#56

Post by isostatic »

throwaway98434 wrote: post #54
isostatic wrote: post #32

Earlier quoted context omitted.

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

Right, someone working in ubuntu distro development has done this work for those packages specifically. Above, we're discussing some build system where someone hasn't done this work. Most collections of python code in the world (I'm going to hazard a guess significantly upward of 90%) just use /usr/bin/python or /usr/bin/env python. That's the nature of the problem.

You're discussing RHEL7's /usr/bin.

  > For example, out of about 50 or so /usr/bin/python scripts I see in a RHEL7's /usr/bin
I posted Ubuntu 1604's in comparison.

Re: What, No Python in RHEL 8 Beta?

#57

Post by zenlot »

zamadatix wrote: post #37
zenlot wrote: post #29

Earlier quoted context omitted.

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.

RedHat(IBM) employee?

Re: What, No Python in RHEL 8 Beta?

#58

Post by throwaway98434 »

isostatic wrote: post #56
throwaway98434 wrote: post #54

Earlier quoted context omitted.

Right, someone working in ubuntu distro development has done this work for those packages specifically. Above, we're discussing some build system where someone hasn't done this work. Most collections of python code in the world (I'm going to hazard a guess significantly upward of 90%) just use /usr/bin/python or /usr/bin/env python. That's the nature of the problem.

You're discussing RHEL7's /usr/bin. > For example, out of about 50 or so /usr/bin/python scripts I see in a RHEL7's /usr/bin I posted Ubuntu 1604's in comparison.

I'm discussing the problem of collections of python scripts using /usr/bin/python and I included the state of RHEL7 as an example.

The actual subject is CoolGuySteve's build system, which is likely to look like my example of RHEL7 rather than yours of ubuntu. The vast majority of environments look like RHEL7 or CoolGuySteve's build system where #!/usr/bin/python is the norm.

Re: What, No Python in RHEL 8 Beta?

#59

Post by isostatic »

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.

No doubt they have one of those "curl http://site.com/script.sh && sudo bash script.sh" installation instructions.

Sigh.

Re: What, No Python in RHEL 8 Beta?

#60

Post by vetinari »

rleigh wrote: post #53
vetinari wrote: post #52

Earlier quoted context omitted.

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

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…

Transitive dependencies (or what I called inherited from other packages) can be solved with pip freeze in existing working environment; it will list them too.

New development, on the other hand, will be difficult. As it usually is, when you develop in something that has been obsoleted years ago. If you are still developing the system, instead of just keeping it running, shouldn't you spend some resources on python3 migration, too? The modules you need are already there.

Post reply on HN