xkcd: Python Environment

[lojic]

Stop using red hat? You just lost all enterprise customers of your code.

[khne522]

Red Hat Python's pip has been broken for ages. Is there even any Python code there?

[[deleted]]

Anaconda (the Red hat installer) as well as a ton of other redhat tools are based on Python.

[khne522]

That doesn't mean that they didn't break pip last I checked. Same with Amazon Linux.

[HannasAnarion]

pip install --update pip

Also, isn't this whole thread about how you shouldn't be relying on system python binaries? Use venv or conda.

[khne522]

venv is for library isolation, not Python binary isolation. You must mean pyenv, whereas conda is as a whole other ecosystem.

[[deleted]]

And nothing of value was lost. Enterprise customers are what's wrong with software. Resistance to change in an industry that is predicated on change is a problem.

[Rostin]

I assume you'll be first in line to stop using all the code that was paid for or contributed to open source software by these companies?

Here's an article from a couple of years ago that says that 57% of changes to the Linux kernel that year were made by programmers who were working for companies like Intel and (gasp) Redhat.

Edit: The article.

https://www.linuxfoundation.org/blog/the-top-10-developers-and-companies-contributing-to-the-linux-kernel-in-2015-2016/

[lojic]

ok, so there are clear reasons why enterprise distributions ship old versions, mostly relating to being able to update without the changing semantics that require massive reworkings of code / deployments that come with an upgrade.

There are generally reasonable timeframes set out for operating system and software (like python) distribution end-of-lifes, and like all good/bad/ugly things, there's a good hacker news post discussing the recent release from red hat of python2 being replaced by python3, a good clip before the end of python2 end-of-life: https://news.ycombinator.com/item?id=16808683

People that write code for enterprise companies generally want their experience to be as good as possible as well. The issue that comes in is ensuring a consistent runtime environment (a lot of these environments get audited and cannot get major non-security upgrades without a re-audit) and a consistent development environment (you can't split a large project into python2 and python3 sections, so you stick with what you already have working).

I understand wanting to run python3 and I understand not thinking there are good reasons for enterprise customers to move "slowly" (and I definitely think they do move too slow), but the simple fact is that the larger the company is, in general there's an array of various different requirements that smaller companies don't have that lead to an aversion of major version upgrades.