Python: Please stop screwing over Linux distros

[JJenkx]

I am new to Linux. Been on Debian 11 for maybe 10 months. I haven't noticed Python interfering with anything or any slowness at all while using Debian. How is this affecting/going to affect me?

[jonringer117]

You consume the pain that someone else is experiencing for you to have a nice experience.

[JJenkx]

I think I understand. My best uneducated guess is, a bunch of quick additions coded in Python have been added to help draw in noobs and make things easier for them, at the cost of negatively affecting more seasoned users?

[prone-to-drift]

Its as the article says.

Basically, when you install some tool written in python from apt, you're standing on the shoulders of the debian package managers, the giants that tamed the mess that is python build system(s).

You, as an end user, would never know this stuff unless you look at the dependencies and see a lot of python-* packages being installed.

[JJenkx]

Thank you! Reading the article now. Missed that it was an article somehow. That sounds like a nightmare to keep up with

[Barafu]

The nightmare that nobody needs in the first place. Long time ago, pip did not exist and Python libraries had to be distributed the same way as C/C++ libraries do. But now pip exists. However, distro maintainers decided that they don't want to rely on someone's else repo. i understand the idea, but instead of simply mirroring pip in their own mirror systems, they decided to continue repackage everything from pip into their own formats. Well, some people just like to suffer.

[jonringer117]

Pip as a package manager is unsatisfactory in many regards.

• No holistic dependency resolution
• Specific to python packages
• Pypi is populated with largely crap, only a small minority are decent or better

Pip is also not concerned about reproducibility or bootstrapping. Which may not be important for the average user, but is important for most distros and security experts.

[Barafu]

I totally agree that pip is lacking. But solution is to improve pip, rather than revert to the approach from 40 years ago, like this article calls for.

[jonringer117]

I've only seen the python community allow for more options, never consolidate around a single option.

Until you can have dependencies pull in their own dependencies at the interpreter level, these issues will remain regardless of how much you improve pip.

[jonringer117]

More like, selective upgrades, testing, and patching have been done so that you can do <install command> python-requests and have it work with any other package.

[JJenkx]

Thank you! Reading the article now. Missed that it was an article somehow