Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python: Please stop screwing over Linux distros

drewdevault.com

Post reply on HN
Print view View original

321–330 of 384 posts

Re: Python: Please stop screwing over Linux distros

#321

Post by cozzyd »

josefx wrote: post #283
thereddaikon wrote: post #267

Earlier quoted context omitted.

Fortunately there are a thousand gigabytes in a terabyte and nobody is using a system with single or double digit gigs of storage anymore. Unless you are trying to save a buck it seems 1TB is the standard today. My primary desktop has 4.

> Unless you are trying to save a buck it seems 1TB is the standard today. Buying a 1TB external SSD would more than double the cost of a raspberry pi 4 that and my ancient beagle board does fine running from 32 GB. > My primary desktop has 4. Those are rookie numbers for a primary system. Of course my Office system next to it is a lot lower specked with the test system next to it even lower.

The eMMC on a Beaglebone Black is 4GB. Sure you can boot off an SD card but that's less robust (though, I guess you can use the SD card for all your virtualenvs...).

Re: Python: Please stop screwing over Linux distros

#322

Post by cozzyd »

pimterry wrote: post #95
captainmuon wrote: post #74

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…

One case where disk space is somewhat scarce is on shared academic computing clusters (which often provide many versions of things via some module system, but your $HOME can have a quota that's just 30GB).

Re: Python: Please stop screwing over Linux distros

#323

Post by salawat »

formerly_proven wrote: post #164
salawat wrote: 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…

> the dist-packages folder, which is shared between system Python runtime versions. I mean... I understand how hypothetically this could in theory make some sense because a distro might naively expect to ship the same package version for different Python versions and so all files could be the same except for native extensions, which are disambiguated by implementation name, so theoretically one could imagine a positi…

I never blamed Python for it per SE, because that is 100% a packager thing.

It's definitely the distro's fault (cough Ubuntu cough).

>This is something that can only happen because someone went extraordinarily far out of their way to shoot someones else's foot off.

Ding ding ding.

Re: Python: Please stop screwing over Linux distros

#324

Post by salawat »

Joker_vD wrote: post #131
salawat wrote: 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…

Ah, so that what happened in my anecdotal story in another comment in this thread [0]. But why would you need a newer python3 anyway? The package maintainers ship 3.6 by default for a reason and they know better than you! /s [0] https://news.ycombinator.com/item?id=29238700#29239446

In my case? Recreating a build environment in the process of debugging an issue with a build script and trying to get the runtime environment lined up just so; with a side objective of an exploration of the madness of how Python as a language handles packaging (part of which was what kind of footguns are presented by the lang specific package manager, which funnily enough also seems to be completely oblivious to the runtime version it's executing in).

>The package maintainers ship 3.6 by default for a reason and they know better than you! /s

Maybe then! Not anymore! It really does infuriate me because it breaks every aspect of the principle of least surprise and conventional software packaging practice.

Re: Python: Please stop screwing over Linux distros

#325

Post by cozzyd »

pfranz wrote: post #87
turminal wrote: post #49

Earlier quoted context omitted.

Language specific package managers are the antithesis of package management. There is no "management" in "install multiple versions of stuff in this 10 levels deep dependency tree". Upstreams can pick their dependencies but at the same time cannot control what packages depend on them and make it into your app and neither can you. That's a job for your distro.

What happens if your project needs an update, but it will hose the OS? Do you expect someone working in Python in Windows who wants to distribute a datetime package should package for RPM and APT? I used to think OS package managers should be the end-all be-all, but the use cases for OS package managers are very different from language runtimes. While different Linux distros were fighting between themselves, they com…

One of the annoying things is python setup.py bdist_rpm seems essentially deprecated (though it still works somewhat).

Re: Python: Please stop screwing over Linux distros

#326

Post by cozzyd »

isolli wrote: post #39
fer wrote: post #28

This is my decision flow and I rarely have an issue: Are you the end user of the Python code? Yes -> Is available in your distro? Yes->Use package manager No->Use pip install in user mode No -> Create virtualenv with the Python version you want (including pypy!) and do your pip thing there Some extreme use cases may benefit from anaconda, but personally I've never needed to use it. My only pain point is dealing with…

Hm, why? I'm a happy user of PYTHONPATH!

Yeah, how else do you git clone some random package and immediately use it without "installing" it?

PYTHONPATH is simple and obvious how to use, and is similar to using LD_LIBRARY_PATH and friends.

Re: Python: Please stop screwing over Linux distros

#327

Post by cozzyd »

doubleunplussed wrote: post #43
isolli wrote: post #39

Earlier quoted context omitted.

Hm, why? I'm a happy user of PYTHONPATH!

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.

So is PATH and LD_LIBRARY_PATH. You just change those as you need to...

Re: Python: Please stop screwing over Linux distros

#328

Post by [deleted] »

WhyNotHugo wrote: post #75
cdent wrote: post #46

I'm always confused by these sorts of posts because they happen often so there is clearly a problem but for some reason I've never had much of an issue. I've been using and developing with Python for about 15 years. In that time I've worked on Python projects large (OpenStack) and small (gabbi) and taken over maintenance for some old standbys (wsgi-intercept, paste to name two). Dealt with the 2->3 transition. Releas…

So there's a few types of projects you can write in Python: 1. Server applications that run in a dedicated environment. 2. Tools you write and run just on your machine (or some virtualenv, whatever). 3. Redistributable cli or desktop applications which end users will install and use. For the first two types, you should never have any issues with Python and its dependency situation. You pin everything, and that's it.…

[deleted]

Re: Python: Please stop screwing over Linux distros

#329

Post by hk1337 »

nerdponx wrote: post #92
captainmuon wrote: post #74

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.

I hate that Homebrew uses /usr/local. At least on M1 they had to move it to /opt but I always install it to my home directory in ~/.brew. I can override the paths and not have to worry about file/directory permissions.

Re: Python: Please stop screwing over Linux distros

#330

Post by isolli »

doubleunplussed wrote: post #43
isolli wrote: post #39

Earlier quoted context omitted.

Hm, why? I'm a happy user of PYTHONPATH!

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.

Alright. I actually set it in a Docker container. It works well there.
Post reply on HN