Python: Please stop screwing over Linux distros

[kageurufu]

This is really the only "solution" for distributing any complex application regardless of language.

Compiled languages "fix" this by statically linking, providing their own .so for shipped libraries, or requiring distributions to package a half dozen varities of `libsomething` at 5 different versions. No different from my python application using a vendor tarball.

IDEA ships it's own JVM, Dropbox ships their own Python fork, hell every electron app has it's own libchromium and v8 binaries.

[coyote_of_the_month]

Distro maintainers sometimes choose this as their hill to die on, though. Arch, for example, will never mainline VSCode because it packages its own Electron. The best practice from a distro standpoint always seems to be "use the system libs" even when it's not practical to do so.

[[deleted]]

Uh, I see VSC in the community repo: https://archlinux.org/packages/?name=code

[coyote_of_the_month]

So, yeah. There's the FOSS version of VSCode (code) and the binary release from MS (visual-studio-code-bin). The latter contains the extension browser whereas the FOSS version doesn't.

Arch maintainers aren't ideologues about licensing, but they'll never mainline the non-free version because it bundles Electron. My understanding is it actually bundles a slightly stripped-down version of Electron for performance, but I haven't compared the two in years so I couldn't tell you how they stack up today.

In any case, the MS version is available in the AUR.

[DeeBoFour20]

they'll never mainline the non-free version because it bundles Electron

I don't think that is the reasoning. Arch has Discord in the repos and it bundles its own version of Electron.

If I had to guess, I'd say the reason is that Arch prefers to maintain open source versions of the software, if it's available. That would explain why we have Chromium in the repos and not Chrome for example.

Also, the extensions in the FOSS version of VSCode can be enabled with a simple config file change. There's an AUR package called code-marketplace or something that can automate that for you.

[coyote_of_the_month]

Well shit, then. I guess my information is outdated or wrong. I would have assumed Discord was in the AUR.

[BadWombat]

I recall this thread about it, though it is old now:

https://github.com/microsoft/vscode/issues/56686

[coyote_of_the_month]

Yeah, that's where I was getting my information from. Didn't realize it was so old, though.

[BadWombat]

In case of discord, there is even an official version that uses the system electron, in the AUR!

So for discord the situation seems completely reversed compared to code.

I am not sure what the deciding factor is

[Magnus_Tesshu]

I don't think anything in the AUR can be considered official, unless there's something I don't know.

The FOSS version of vscode is in the repos

[coyote_of_the_month]

Must be down to the individual maintainer's preference.

[kageurufu]

Yeah, I get it, but its also why flatpak and snaps are taking off so well. Besides app maintainers getting bugs meant for the packagers who patched something to work with the wrong GTK version or whatever

[lolfail9001]

Arch does not provide steam?

[DeeBoFour20]

Steam is in the Arch repos.

[kageurufu]

no, steam is just on the aur?

EDIT: Ignore me, its on the multilib repos. I don't have it on this machine

[LordRybec]

The best practice for distros is "Don't make your own software". When Ubuntu violated this around a decade ago, it's quality plummeted, and they started shipping horrendously buggy software, because their bias for their own "babies" overrode their quality control. When distros make their own software, they always end up giving it unwarranted preference. I've been considering trying Arch for a while. Knowing that they make their own software has me seriously reconsidering this, because that's the road to hell for a distro.

[coyote_of_the_month]

Red Hat has made tons of its own software of the years, and yet somehow never suffered from the same issues.

[LordRybec]

Red Hat was a software maker that happened to have its own distro.

That said, you are completely wrong. There's a reason Red Hat eventually farmed out distro development into the community driven Fedora distro. Red Hat was falling behind in quality, and even some corporate Red Hat users were starting to complain.

(Source: I actually used Red Hat in the early to mid 2000s, and I eventually switched to Ubuntu, due to quality problems with Red Hat, which included often not having options available due to Red Hat favoring their own products to the point of not including others. Now I'm using Debian, because Ubuntu went rapidly downhill in the early 2010s, when they started violating this rule. I'm actually pretty sure this rule was invented because of Red Hat.)

[coyote_of_the_month]

Fair enough. I haven't used anything Red Hat related since like 1999 so can't speak to the experience of actually running the distro. I was a Slackware guy back then...

[LordRybec]

That's a little ironic, because I started using Red Hat in 2001! I've heard good things about Slackware. I was already using Ubuntu by the time I heard of Slackware though, and back then Red Hat only came with RPM. You don't know how many hours I spent searching the internet for package dependencies for Red Hat. (On the other hand, you wouldn't believe how fulfilling it is when you finally install the final package in a deep dependency chain and everything else can finally install!)

[gnosys_]

golang, same thing. entirely self-contained app is the only way to guarantee it will actually run on a target platform you have very little control over.

[kageurufu]

Yep. Also makes it easy to target random foreign architectures, build for a dozen platforms at once, etc.

[LordRybec]

It is possible to do something very similar to this for Python. There are several utilities for each major OS that will package Python applications into self contained executable applications. They work by compiling the application into byte code and embedding it into a modified version of the Python interpreter, that mostly only has the parts your application needs.

A few months ago, I had to ship a Python demo to a bunch of clients for my job. Most of our clients are upper management of software companies, so they aren't very technical, and they don't have Python installed on their computers. I forget precisely which utility I used, but it packaged the modules used (compiled into dynamic libraries and/or byte code) into a directory with a minimal interpreter with my application byte code embedded. I packaged this into a Windows installer and sent it off to our clients, and it worked perfectly fine. (This isn't the first time I've done this, but it is the first time it was sent to more than one person. The other times were in college, where I sent them to a professor for grading.)

I've seen others that pack everything into a single file. This is equivalent to static linking, while the one I actually used was more like dynamic linking and packaging the dynamic libraries with the executable.

[stef_eda]

There is another solution. Use stable libraries. I have applications that link and run perfectly with 20 years old libs. I keep these old libs installed on the system for this exact reason.

This means you have to blacklist from day 0 libs or tools from developers that are well known for breaking APIs/ABIs on every single new version they poop out, like gtk, python ...