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

131–140 of 384 posts

Re: Python: Please stop screwing over Linux distros

#131

Post by Joker_vD »

salawat wrote: post #58
formerly_proven wrote: post #20

Earlier quoted context omitted.

Your last sentence doesn't parse for me at all. How exactly do you get a pip installed on Python 3.6 to modify anything about another install of Python, let alone a different version?

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

Re: Python: Please stop screwing over Linux distros

#132

Post by __float »

1337shadow wrote: post #76
dolmen wrote: post #55

Earlier quoted context omitted.

Looks like the "Works on my machine" syndrome. What about working on a project with a team? What about deploying the code on another machine?

Then I go with something like docker-compose

Docker is a very heavy-handed approach to mitigate more fundamental issues with Python's package management, don't you think?

Re: Python: Please stop screwing over Linux distros

#133

Post by BiteCode_dev »

1337shadow wrote: post #116
BiteCode_dev wrote: post #108

Earlier quoted context omitted.

Sure, so my lib works on mac, windows, centos and debian. Tell me how I'm supposed to define my lib python deps ? How am I suppose to package the lib ? Distribute it ? Deal with os versions differences? Allow isolation for my user projects ?

I'm sorry, doesn't pip already works there? Otherwise, there's pyinstaller which is great but it requires an entrypoint so it won't do with a pure lib that doesn't expose any script at all.

Yes that's the point. We won't use distro packages because only regular python packages allow this.

Edit : arf, sorry, I answered the wrong comment, I actually agree with my parent.

Re: Python: Please stop screwing over Linux distros

#134

Post by toyg »

ajsnigrutin wrote: post #120
cjfd wrote: post #97

Earlier quoted context omitted.

Perhaps the distributions would be more inclined to include up-to-date version if the standard in the python community was not to break everything all the time. There are distributions that keep up-to-date, though, e.g., archlinux. Serving the needs of python developers vs. sysadmins is a false dichotomy. Python developers develop on a system that they need to admin. One great thing about linux is that everything on…

> Perhaps the distributions would be more inclined to include up-to-date version if the standard in the python community was not to break everything all the time. Yep... Perl is a godsend... take a code from 20 years ago, run it on a modern system, and everything works. Python? Three different software versions need three different versions of the same library, and new library versions are not backwards compatible wi…

> Perl is a godsend... take a code from 20 years ago, run it on a modern system, and everything works.

That's more or less like "take a VB6 binary from 20 years ago, run it on some modern Windows, and everything works" - that's just because the ecosystem is effectively dead, so supporting it on new releases just means carrying over some stuff that worked 20 years ago.

Re: Python: Please stop screwing over Linux distros

#135

Post by BiteCode_dev »

simonh wrote: post #114
BiteCode_dev wrote: post #101

Earlier quoted context omitted.

Yes, explaining to a beginer how to bootstrap python is hell because windows, mac and linux keeps making sure nothing work the same.

Actually, explaining how to get Python working on Windows is far, far easier than on either linux (modulo various distros) or the Mac. That's because there is one obvious distribution of Python to use, the official one, and new versions of it are always consistent and play well together. Yes you can use Anaconda if you want, and people who do that are probably data scientists or something and know what they want to d…

Unfortunatly windows has plenty of problems too. First, the system PATH will kick you if of you have more than one python installed, so the official installer does not add to it by default, hence the python command doesn't work after an install. Instead, you get the py launcher, but it's not provided if you installed python from the app store or with anaconda.

The you have powershell permission system.

It's a ton of fun.

Re: Python: Please stop screwing over Linux distros

#136

Post by eigengrau »

BiteCode_dev wrote: post #98

The day packaging for distros will be easy, we will use it. Right now, making a deb is hard. Isolating 2 projects with different deb verions is hard. Distributing debs is hard. Upgrading your OS but not your python debs is hards. Then rinse and repeat for red hat, arch, nix, mac and windows ? Yeah right.

Since Nix packages are distribution-independent, once you have it packaged with Nix, you could theoretically skip packaging for Ubuntu etc., but of course that may raise the bar of entry for your users.

Re: Python: Please stop screwing over Linux distros

#137

Post by kevinmgranger »

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 have ever said "why do you need to do that" as an accusation instead of with curiosity, you exemplify the problem.

Re: Python: Please stop screwing over Linux distros

#138

Post by jacquesm »

toyg wrote: post #127
nerdponx wrote: post #92

Earlier quoted context omitted.

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'll remember that "Homebrew does this very well" the next time I have to fix a bunch of shit because it has updated the currently-active version, or removed this or that bugfix release, as part of a general upgrade. After the third time this happened, I started using pyenv - which is another mountain of brokenness, I grant you, but at least I have some degree of control on what happens when.

I'm using Anaconda, it's so far hands down the best way to manage python and its packages. It just works.

Re: Python: Please stop screwing over Linux distros

#139

Post by kijin »

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…

It's not just about disk space, though.

Distros assume responsibility for fixing major bugs and security vulnerabilities in the packages they ship. Old versions often contain bugs and vulnerabilities that new versions don't. Distros have two choices here: either ship the new version and remove the old version, or backport the fix to the old version.

Continuing to ship the old version without the fix is not an option -- even if you also ship the new version -- because some programs will inevitably use the old version and then the distro will be on the hook for any resulting hacks. Backporting every fix to every version that ever shipped is also not a realistic project.

Here in the startup world we often forget that there's a whole other market where many people would gladly accept 3-year-old versions in exchange for a guarantee of security fixes for 5-10 years. Someone needs to cater to this market, and the (non-rolling) distros perform that thankless task because individual developers won't.

Re: Python: Please stop screwing over Linux distros

#140

Post by 1337shadow »

__float wrote: post #132
1337shadow wrote: post #76

Earlier quoted context omitted.

Then I go with something like docker-compose

Docker is a very heavy-handed approach to mitigate more fundamental issues with Python's package management, don't you think?

I'd say it's a heavy-handed approach to mitigate more fundamental issues with how python packages are maintained, if everybody wants to pin different versions then we're going to have to install different versions of everything which is what npm does and I consider that heavier.

Again, it's all a question of point of view, what we see as a package manager problem and causes us to keep reinventing packages managers, might actually be a problem with how we maintain our packages, my point of view being the latter. But I'm digressing.

When it comes to installing on "another machine", you don't know what Python they have, you don't know what libc they have, and so on, that is exactly what containers attempt to mitigate, so that seems exactly like the tool to use for this problem.

Post reply on HN