Live data from Hacker News

Python: Please stop screwing over Linux distros

drewdevault.com

341–350 of 384 posts

Re: Python: Please stop screwing over Linux distros

#341
post #331
post #202

Earlier quoted context omitted.

And people will still be shipping code faster and more efficiently than they would do in Perl. Because in the end, the advantages of using Python, in terms of readability and productivity, easily offset a bit of packaging pain - whereas the disadvantages of using Perl don't offset whatever marginal gain you get by using old infrastructure.

As an end user, I care more about code quality and stability than I do speed of shipping code. I don't want to use some buggy code that was pushed through production too quickly just because the devs are lazy!

Yep... if a thing works, don't fix it.... Modern devs "fix it" until it's broken. Just look at google and their communication platforms... every few years a new one that kills off the previous one, with practically no added value.

There is a lot of software, from 7zip, total commander, putty, vlc, windirstat, etc., that do one (or few things), people have been using them for decades, and pretty much all the features have been there for that long, without an artificial need to "ship something new, fast" every few weeks.

Re: Python: Please stop screwing over Linux distros

#342
post #70
post #58

Earlier quoted context omitted.

Apt install python-pip3 You'll get pip3 from Python 3.6. apt install python3.8 You'll get system-level python3. Use pip3 in 3.6 to install the latest pip3 that requires Python 3.8, and drops that package in the dist-packages folder, which is shared between system Python runtime versions. Behold as further attempts to do something sane with APT blow up, because now you have 3.8 packages on 3.6's runtime path. I've los…

"Thou shalt not mess with the system Python"

Given, and yes I've heard that before, but I counter with:

If you don't want someone to mess with it, name it as something other people will not regularly have a reason to muck with. One concerted effort to ship distro's with a "sys-python" symlink instead of /usr/bin/python, and for all things currently using the newly minted sys-python stuff can be free of wayward travelers and system sculptors like me mucking with things.

No, pyenv is not the answer. Naming things is.

And trust me. I get it. It's a rite of passage learned in due time, yada-yada. Got it. If we ever want to get this stuff easier to use though, we have to be willing to help draw clean distinctions between this and that. Virtual environments don't do that until it is far too late and a beginner is already in and over their head in breakage.

Re: Python: Please stop screwing over Linux distros

#343
post #276
post #117

> What is it about Linux distros that makes our use-case unimportant? Have we offered no value to Python over the past 30 years? Indeed you haven't. Worse, you've actively damaged Python's efforts to improve. I mostly work on the JVM these days, and I think one of the main reasons dependency management there is so gloriously simple and effective is that the Debian packagers weren't around to fuck it up.

There is plenty of Java packages in APT.

There are now, but for a long time they had to live in contrib because Java wasn't open-source, and so apt didn't deeply integrate and customize their package management the way it did with perl or python.

Re: Python: Please stop screwing over Linux distros

#344

Earlier quoted context omitted.

And yet, other languages ship package managers [1] that are widely loved within their ecosystems and cover everything from microcontrollers to server applications. I think what it makes it more difficult in the case of Python is that it has decades of legacy to deal with. No consistent semantic versioning, packages that expect that they can modify their package path in-place (this is a nightmare for immutable systems…

Cargo is a good example of a survivorship bias of sorts. It's so deeply integrated into rust that if you can't stomach it you just leave the ecosystem and everyone that remains likes it ;)

Hm, so what did you dislike about `cargo`?

Re: Python: Please stop screwing over Linux distros

#345
post #63

Earlier quoted context omitted.

Is it fair to compare an interpreted language and its package manager to Rust and Cargo? Python packages ship their source (in most cases), depend on a locally installed interpreter (with semantics possibly changing by version). Yes, Python packages often make poor assumptions about what setup.py can do (i.e., _anything_), and so you end up choosing between "tested, supported by the author, and old" or "untested, uns…

Cargo started as a port of Ruby's Bundler. If Ruby can do it, Python certainly can.

Don't underestimate the culture differences between the Ruby and the Python communities.

With Ruby, you are expected to update frequently. New ruby versions are eagerly awaited and all the major packages are updated pretty quickly.

Re: Python: Please stop screwing over Linux distros

#346

Earlier quoted context omitted.

Worth noting that the PSF has no authority to tell people how to do their packaging. Rust's Cargo is 20 years newer than Python and benefits from those decades of experience. It's a very different proposition to start a new system from fresh than to try to migrate a huge and diverse community towards it.

This is actually where a BDFL should step in. "We're doing X for Python 5, we're using it to manage the stdlib as well as community packages, everyone get ready because I have decided."

They tried this with pip.

Distros ripped it out.

They added the ensurepip module so users could add it after the fact.

Distros ripped it out too.

Arguably the advantage newer languages like Rust and Go have in this regard is they don't even consider the distro use case - you're going to get static linking and you'd better like it. Whereas Python is from an older era and tries to fit in with the local customs and so gets hammered for its inconsistency

Re: Python: Please stop screwing over Linux distros

#347

Distro maintainers say that language ecosystem packaging makes it hard for them. Language ecosystem packaging maintainers say that distro package managers make it hard for them. The year is 2021 and there is no work towards synthesis. It will be endless, fruitless yelling from each side. Maybe 2022 will bring change. I'm not holding my breath. To anyone who finds themselves on a single "side" in this argument: if you…

Question is are the other languages saying the same thing about the distros? Or is this just a python thing

Rust/Go/Node mostly just ignore distro packagers entirely.

Java sometimes has these issues, but mostly distros aren't going around splitting up fatjars for desktop applications or wars for Web applications.

C# just gets shoved into opt as it was considered a problem child to be left alone for a long time.

Perl has avoided this problem by stagnating at the cost of its long term userbase.

C/C++ mostly get along fine since the distro package model was built for them, but occasionally someone gets upset about meson or ninja or something.

Re: Python: Please stop screwing over Linux distros

#348
post #60

Earlier quoted context omitted.

Well, that's not true: - Almost all distros don't just supply one version of a package. They try to avoid it, but I can't recall one with a hard rule against it. For instance, Debian packages multiple versions of autoconf https://packages.debian.org/search?keywords=autoconf2 , the Linux kernel, etc. - One reason that distros try not to install multiple versions of a package is that it's hard to specify which one you…

> The possibility you haven't accounted for is "The library ecosystem is like that because things are fast-moving, because people have actual problems they want to solve, and upgrading dependencies and sorting out conflicts is work." Sorry, I was overly aggressive in my previous comments. All I want is the Python ecosystem to acknowledge some people prefer stable over fast moving, recognize the importance of that and…

They have acknowledged it, noted the use case, and decided that they are unable to support it. Python has this in common with most other programming languages.

Providing long-term backwards compatibility with the ability to share libraries and update them system-wise is difficult and imposes very high costs on an ecosystem. Only a small number of tech stacks have ever done this (for example, C and Perl) - and not only are they so old that it wasn’t a conscious choice, they have stagnated as a result.

Re: Python: Please stop screwing over Linux distros

#349

Earlier quoted context omitted.

It's completely global, shared by all Python interpreters of all versions. I set PYTHONPATH, but the code in that directory is solely small debugging utils of mine that I want available in every Python interpreter, and I make sure not to put anything more complex in there.

"It's completely global" It doesn't have to be. You can have a launcher for a project that sets PYTHONPATH just when you launch that project. What is bad practice is to be setting PYTHONPATH in your .bashrc, and for the reason you give - that makes it global across python launches.

That'll prevent it leaking to most things, but not to subprocesses of your application.

For example your application might interact with command-line tools written in Python, and unless you delete PYTHONPATH from the environment variables prior to launching any subprocesses, they'll inherit it. This could lead to subtle and confusing breakage.

Re: Python: Please stop screwing over Linux distros

#350

Everyone complained, no one addressed the fact that for years the whole of python packaging was handled by like 2.5 people. But as a rant this, like most of the ‘but just fix it’ rants, fails to acknowledge the hugely diverging needs of different users. I could not live without conda, since it’s the only sane way to get a working recent geospatial stack. Others need to run embedded environments, or portable ones, som…

I'm not saying it solves every problem for everyone, but have you looked at Nix? I've found it to be great for portability (at least on other Linux distros), and you can easily install anything from stable nixpkgs packages to Git repos. I'm currently using it to manage OS packages and development dependencies for some of the projects I work with (a couple at Work™).
Post reply on HN