16 ms·

What, No Python in RHEL 8 Beta?

zenlot 8y ago
"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.
- sli 8y ago
  Install instructions are right at the top and are typical `yum` commands that RHEL users should already know.
  - zenlot 8y ago
    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?
    - zamadatix 8y ago
      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.
      - zenlot 8y ago
        RedHat(IBM) employee?
        zamadatix 8y ago
        Me? Nah, I'm just a user of RHEL in the healthcare space.
wyldfire 8y ago
> 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 lot of share for the enterprise linux marketplace (maybe #1 or #2?), so maybe they can afford it. RHEL customers should dust off their Python2 source and seriously consider migrating to straddle both 2 and 3 for now. Although the fact that RHEL8 provides ten years of Python 2 support means that they're unlikely to feel that pressure any time soon.
- mkesper 8y ago
  The whole eco system stops caring about Python2. Everybody using Python will suffer if they rely on using Python2 until 2030.
  - rleigh 8y ago
    Unfortunately though, the whole ecosystem hasn't stopped caring, and is unlikely to anytime soon. They should care, but they either don't care or can't migrate quickly enough. Migration can be phenomenally expensive and introduce a ton of bugs. Python 2 will be the IE6 of this era. It's too entrenched to abandon. On the other hand, it will slowly fade into obscurity as migrations occur and old projects die. 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.
- mistrial9 8y ago
  > 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..
CoolGuySteve 8y ago
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 to make an anaconda install or virtualenv the default python for each user.
- mavhc 8y ago
  Wouldn't you just specify the dependencies in your installer so it just works?
  - CoolGuySteve 8y ago
    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.
    - Spivak 8y ago
      Which is fine but how do you specify dependencies right now? Surely a minimal install of RHEL doesn't have everything you need.
      - mroche 8y ago
        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?
        Spivak 8y ago
        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.
PaulHoule 8y ago
Woo hoo!
swalsh 8y ago
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 installing approach isn't bad.
- nitroll 8y ago
  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
nailer 8y ago
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?
- rterzi 8y ago
  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.
- dralley 8y ago
  Fedora doesn't ship with any Python 2, all the utilities in the default installation are Python 3.
  - rterzi 8y ago
    "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.
- jlgaddis 8y ago
  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?)
  - mroche 8y ago
    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
deleted 8y ago
[deleted]
dade_ 8y ago
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.

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

sli 8y ago
Install instructions are right at the top and are typical `yum` commands that RHEL users should already know.
- zenlot 8y ago
  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?
  - zamadatix 8y ago
    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.
    - zenlot 8y ago
      RedHat(IBM) employee?
      - zamadatix 8y ago
        Me? Nah, I'm just a user of RHEL in the healthcare space.

wyldfire 8y ago

> 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 lot of share for the enterprise linux marketplace (maybe #1 or #2?), so maybe they can afford it. RHEL customers should dust off their Python2 source and seriously consider migrating to straddle both 2 and 3 for now. Although the fact that RHEL8 provides ten years of Python 2 support means that they're unlikely to feel that pressure any time soon.

mkesper 8y ago
The whole eco system stops caring about Python2. Everybody using Python will suffer if they rely on using Python2 until 2030.
- rleigh 8y ago
  Unfortunately though, the whole ecosystem hasn't stopped caring, and is unlikely to anytime soon. They should care, but they either don't care or can't migrate quickly enough. Migration can be phenomenally expensive and introduce a ton of bugs. Python 2 will be the IE6 of this era. It's too entrenched to abandon. On the other hand, it will slowly fade into obscurity as migrations occur and old projects die. 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.
mistrial9 8y ago
> 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..

CoolGuySteve 8y ago

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 to make an anaconda install or virtualenv the default python for each user.

mavhc 8y ago
Wouldn't you just specify the dependencies in your installer so it just works?
- CoolGuySteve 8y ago
  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.
  - Spivak 8y ago
    Which is fine but how do you specify dependencies right now? Surely a minimal install of RHEL doesn't have everything you need.
    - mroche 8y ago
      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?
      - Spivak 8y ago
        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.

PaulHoule 8y ago

Woo hoo!

swalsh 8y ago

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 installing approach isn't bad.

nitroll 8y ago
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

nailer 8y ago

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?

rterzi 8y ago
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.
dralley 8y ago
Fedora doesn't ship with any Python 2, all the utilities in the default installation are Python 3.
- rterzi 8y ago
  "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.
jlgaddis 8y ago
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?)
- mroche 8y ago
  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

deleted 8y ago

[deleted]

dade_ 8y ago

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.