Live data from Hacker News

Python: Please stop screwing over Linux distros

drewdevault.com

221–230 of 384 posts

Re: Python: Please stop screwing over Linux distros

#221
post #56

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…

> Everyone complained, no one addressed the fact that for years the whole of python packaging was handled by like 2.5 people. If I can make an observation - it has nothing to do with the number of maintainers. The problem is deep, cultural and occupies a difficult space where it might be a bug or a feature. The root cause here is that the Python project, and surrounding community, have little real respect for backwar…

It really does have to do with the number of maintainers. A huge part of the work is not just building a package manager, but coordinating many stakeholders to all use it. That would also mean building a package manager that covers all of those use cases from day one - what's the point of trying to make people use something that doesn't meet their needs. These things are a huge amount of work. Unsurprisingly, other widely used languages have the same situation - dozens of build and packaging systems for C/C++, Java, Javascript...

Re: Python: Please stop screwing over Linux distros

#222
post #33

Python libraries shipped by distributions are so old that this mechanism is mostly useless for python development. This also applies to many others programming languages which have their own packaging systems. While python packaging is indeed messy the needs of traditional linux distributions are by far the least important. Python packaging needs to better serve the needs of python developers, not those of sysadmins.…

> Python libraries shipped by distributions are so old that this mechanism is mostly useless for python development.

Absolutely not. Most distributions ship versions that are released before the distro release freeze.

The whole point of using a distro is to have a reliable and trusted development and production platform.

Re: Python: Please stop screwing over Linux distros

#223

Distros, please stop screwing over Python packaging. It is incredible that Debian/Ubuntu pick Python apart and put modules into different packages. They even create a fake venv command that tells you to please install python-venv. What they should just do is offer a bunch of packages like python3.7, python3.8 that install the official python package wholesale into /usr/python or someplace and then symlink one of them…

Homebrew does this very well with its "cellar" system. Every version of every package gets installed to its own root tree, eg `/usr/local/Cellar/python/3.9.7/`. The currently-active version is then symlinked into `/usr/local/opt/python` and from there into `/usr/local`. I believe Nix and Guix also work this way.

Homebrew does this kinda poorly compared to Nix and Guix. They are a different breed.

For starters, there is no /usr/local symlinking process. It's also possible to have multiple versions of e.g. python installed and active. Homebrew is like a poor-man's Nix.

Re: Python: Please stop screwing over Linux distros

#224

Interesting take. I use Python daily and virtualenv is really good for our use cases (running CI/CD, testing installation and running in production in a container). I am not experiencing too many problems with pip + venv. We also maintain our own libraries and even those were relatively easy to set up. Mypy and yapf also helps to maintain a style and type correctness (do not pass in None accidentally).

I do all of my server side Python development in a container. Whenever I start a new project, I create a dockerfile as a first step. This is the easiest way I have found to make my code portable. The main downside I have found is with IDE support. I use the latest tag, so I get updated containers periodically, which has not been a source of breakages. I have not figured out how to tell VSCode to use the Python in my container for statement completion and validation.

For personal projects on my desktop, I have given up and just use pip install, and then don't try to share those scripts.

Re: Python: Please stop screwing over Linux distros

#225

> Every one of these package managers is designed for a reckless world in which programmers chuck packages wholesale into ~/.pip, set up virtualenvs and pin their dependencies to 10 versions and 6 vulnerabilities ago, and ship their computers directly into production in Docker containers which aim to do the minimum amount necessary to make their user’s private data as insecure as possible. Is this any different from…

The notable language ecosystem which is different is "C on Unix", which grew up with "the system provides the dependencies, it's often easier to avoid a dependency if you can, the program usually needs to be able to cope with whatever version of the dependency the system has, rather than pinning to a specific one". That's the primary ecosystem that most Linux distro package managers developed with as their platonic-ideal-shape-of-an-application, I think.

Re: Python: Please stop screwing over Linux distros

#226

And stop putting everything on the planet into a god damn virtual environment.

Python is basically unusable without venvs in my experience. Not sure what your alternative suggestion is. I hope you don't think global pip install is the right way.

Re: Python: Please stop screwing over Linux distros

#228

Earlier quoted context omitted.

> All decisions related to dependency choices fundamentally belongs with upstream. No. As a user I want dependency management (and all of software distribution, to be honest) to be handled by the party that's best able to keep things working while at the same time keeping them secure. Linux distributions have a much, much better track record at that than most upstreams.

I really doubt that the python libraries packaged by Debian are any more secure or stable than the latest release of those libraries. At best they just limit to breaking updates to once every few years when they update them. It’s essentially like version locking packages except some random Debian maintainer decides when it’s time to update.

The python libraries packaged by Debian are provably more secure or stable: they receive security backports while also not receiving feature updates.

The combination of this 2 aspects is what provides better stability and better security.

> It’s essentially like version locking packages except some random Debian maintainer decides when it’s time to update.

Not at all.

Re: Python: Please stop screwing over Linux distros

#229
>I What is it about Linux distros that makes our use-case unimportant? Have we offered no value to Python over the past 30 years? Do you just feel that it’s time to shrug off the “legacy” systems we represent and embrace the brave new world of serverless cloud-scale regulation-arbitrage move-fast-and-break-things culture of the techbro startup?*

The thing is, people in development wont use the distro python (but different installs, pyenv, etc), and people in devops wont use the distro python either...

So, what values does it offer to whom? Except maybe scripting for sysadmins?

Re: Python: Please stop screwing over Linux distros

#230

Distros, please stop screwing over Python packaging. It is incredible that Debian/Ubuntu pick Python apart and put modules into different packages. They even create a fake venv command that tells you to please install python-venv. What they should just do is offer a bunch of packages like python3.7, python3.8 that install the official python package wholesale into /usr/python or someplace and then symlink one of them…

> Get rid of the requirement that there is only one stable (minor) version of a package in the distribution at one time. I think this requirement made sense when disk space was scarce. I think this requirement makes sense if you trust that your distro is always better at choosing the 'best' version of a dependency that some software should use than the software author. Nowadays, I think neither is generally true. Dis…

> a la pnpm's approach for JS: https://pnpm.io/

Ah JS, how many days has it been since the last weekly "compromised npm package infecting everything" problem? If you are upholding that as gold standard you have to be the worlds laziest black hat.

> Disk is plentiful,

I recently had to install a chrome snap because it is the new IE6 and everyone is all over chrome exclusive APIs as if they were the new ActiveX. Over a gigabyte of dependencies for one application and given the trend of browser based desktop applications? I would like to have space left for my data after installing the programs I need for work.

Post reply on HN