Live data from Hacker News

Python: Please stop screwing over Linux distros

drewdevault.com

381–384 of 384 posts

Re: Python: Please stop screwing over Linux distros

#381
post #255

Earlier quoted context omitted.

Interesting; how would you isolate the system python from the user in Debian/Ubuntu. Do you have a link where I could learn more about this?

You may not be able to completely, but basically if users can write python scripts and run them using system python that's a side effect. It's purpose is to run system scripts, and any other use must not interfere or compete with that in any way. To be hones that wasn't always the case. In the early days Python was provided on these systems for users just as much as administrators and in the early days there weren't…

Ahh, I see! Thanks for the clarification!

Re: Python: Please stop screwing over Linux distros

#382
post #235

Earlier quoted context omitted.

Interesting; how would you isolate the system python from the user in Debian/Ubuntu. Do you have a link where I could learn more about this?

Don't put the system python in $PATH. Any command that needs the system python can be launched through a shim/wrapper script that sets the PATH. (Or even better to execute python directly to avoid passing the system python in PATH.)

Wow. It never occurred to me to approach it that way, thanks!

Re: Python: Please stop screwing over Linux distros

#383
post #269

Earlier quoted context omitted.

Interesting; how would you isolate the system python from the user in Debian/Ubuntu. Do you have a link where I could learn more about this?

I would start by putting it in a path that won't be included in the users default $PATH, perhaps /sbin or /usr/sbin

Ooh, this sounds quite nice. And it would also be compliant with the Filesystem Hierarchy Standard.

Re: Python: Please stop screwing over Linux distros

#384

Earlier quoted context omitted.

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.…

#3 is the exact case where you also want to just pin everything. For an end-user desktop application, you ship a properly tested bundle, instead of trying to support all the different versions; as the end-user (unlike a developer using a lib on their own machine) should not ever have to interpret compatibility issues and should get a package that's been tested to work as a whole. If a distro ships python 3.6 and the…

> For an end-user desktop application, you ship a properly tested bundle, instead of trying to support all the different versions

Good luck trying to get such a bundle packaged into any mainstream distribution.

Post reply on HN