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

331–340 of 384 posts

Re: Python: Please stop screwing over Linux distros

#331

Post by kymaz »

toyg wrote: post #202
ajsnigrutin wrote: post #183

Earlier quoted context omitted.

But it works... it's universally supported on pretty much every os, even by default on most *nix based ones, and new versions and new CPAN modules are still written. In 10 years, with python 4, or even maybe 5, everything will still be broken, and you'll still be claiming perl is dead, and i'll still be using the same stuff I use now, that worked years ago, works now, and will work then.

And people will still be shipping code faster and more efficiently than they would do in Perl. Because in the end, the advantages of using Python, in terms of readability and productivity, easily offset a bit of packaging pain - whereas the disadvantages of using Perl don't offset whatever marginal gain you get by using old infrastructure.

As an end user, I care more about code quality and stability than I do speed of shipping code. I don't want to use some buggy code that was pushed through production too quickly just because the devs are lazy!

Re: Python: Please stop screwing over Linux distros

#332

Post by jhrmnn »

atoav wrote: post #318
jhrmnn wrote: post #104

Earlier quoted context omitted.

To run code developed with Poetry, you shouldn’t even know it’s developed with Poetry. It should be released as a source distribution or a wheel on PyPI or as a conda package if it contains nontrivial binary extensions. These distributions should be then either packaged by the OS or they should be installed with all their dependencies into a separate virtual environment in /opt.

Sure, if I release the code I tend to do just that. However a lot of the code I have been writing was to be used on servers where installing poetry was not an option. That means there was no straightforward, well documented or otherwise easy way to copy the project onto the server an "just have it work". And this was not due to me not taking care of my dev environment. Now I know how to do this, so this is not a prob…

If installing Poetry wasn’t an option, deploying a frozen set of dependencies should be still relatively easy with plain ”pip freeze” and “pip install -r”.

Re: Python: Please stop screwing over Linux distros

#333

Post by cozzyd »

coldtea wrote: post #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 diff…

Many system applications are written in python. For example, the package manager for my system (dnf) is written in python.

Re: Python: Please stop screwing over Linux distros

#334

Post by cozzyd »

robertlagrant wrote: post #78

A suggestion: 1) If your distro requires Python, don't put it on the path. Refer to it another way if you need it, e.g. have a distroname-system-python package you upgrade at your own cadence. 2) That's it. Then developers can install Python how they like, and it's (probably) all fine.

Indeed, many are moving in this direction (https://developers.redhat.com/blog/2019/05/07/what-no-python...)

Re: Python: Please stop screwing over Linux distros

#335

Post by hulitu »

fnord123 wrote: post #105
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.

There are different cadences and roles in play here. Cadences: Distribution - e.g. Ubuntu 21.10, 22.04; RHEL 8.4, 8.5, ..., 9 Library - e.g. simplejson 3.17.4, 3.17.5, ..., 3.18.0 Language - e.g. Python 3.8.0, 3.9.0, 3.10.0 (This makes Python particularly annoying because for a C project it shouldn't matter if you used gcc 8 or gcc 9 when producing binaries, but with Python it very much matters which version of Pytho…

Wouldn't be better if the python programmers did a bit of planning ? Or are the things so boring that every python minor version must be incompatible with other python minor versions.

Re: Python: Please stop screwing over Linux distros

#336

Post by thereddaikon »

kijin wrote: post #311
thereddaikon wrote: post #289

Earlier quoted context omitted.

Why not? Its cheap resource wise whereas dependency hell is potentially debilitating. For some reason many proponents of the package management status quo are blind to this. Having multiple versions of a dependency is only bad in so far as its "messy". It isn't objectively bad. But having a system that breaks applications because two or more cant agree on a package version is objectively bad. Its arguing aesthetics v…

Disk is cheap. RAM is cheap. Man-hours are not. Distros are maintained by people, who are often volunteers. You are asking them to do extra work (i.e. porting the same patch to multiple versions of the same library) so that someone else can have it easy. But why should they? Why not the other way around? It's not just aesthetics. If a new vulnerability is found in, say, libjpeg, then every Windows app that uses libjp…

Not managing that would require less work not more. Their position is making more work for themselves. The point was to prevent dependency hell through matching the wrong package versions. Something that can occasionally happen in Windows. The problem is, the current form of management causes the far worse form of dependency hell of applications requiring conflicting versions.

I have maybe had Windows get confused about dependency versions twice ever and both times it was a driver inf for a virtual device. I will grant that fixing the problem required a fair amount of work by Windows standards but frankly not all that much by the standards of some of the more hands on distros.

I have had Linux tell me I can't install an application because it wanted a different version of Lib-whatever than what something else wants many many times.

"Why should we give up that benefit just because some developer wants to use his own special snowflake version of a library?"

Odd that you claim major distros are built by a small group of volunteers but the maintainers of much smaller and less well supported applications need to suck it up and use whatever version the Distro maintainers decide on.

Most major distros are not volunteer run and haven't been for ages. Ubuntu, RHEL, SUSE, POP, the list goes on. These are commercial products with full time paid developers. In the case of Ubuntu they are providing a major chunk of the work back upstream to Debian and in the case of RHEL they are the upstream. Most minor distros are downstream benefactors of the big players.

Contrary to that its still common for many FOSS apps and utilities to be one man jobs. Maybe the guy doesn't have the resources to keep up with the break neck pace of some update cycles. What if they decided to go with an LTS build intentionally? What if its a simple package that doesn't have security issues yet gets updated for other reasons? What if the version they are using has core functionality that was EOL'd in a newer release so they can't move on without major rework that they can't manage?

There are a million reasons for why a project may want to stick with an older version. Also allowing for the ability to update all packages does not require draconian control of which packages can be installed. This notion runs against the whole notion of user control. If the user wants multiple concurrent versions on their system who are you to say they can't? FOSS means freedom.

Re: Python: Please stop screwing over Linux distros

#337

Post by BiteCode_dev »

hatsuseno wrote: post #313
BiteCode_dev wrote: post #261

Earlier quoted context omitted.

There are some differences indeed: - python is more active than most alternatives, you have new packages created every day. - python is massively used outside of the web, unlike JS, ruby or PHP, that are 99% web. You get Python in SIG softwares, data analytics, automation, pen testing, sysadmin, biology, etc. It's a huge graph. - python is used by the distro themselves to code features of the OS. E.G: you remove Pyth…

Aside from the variety of languages in the extension ecosystem, how does this explain Perl doesn't generally share these dependency issues?

> Aside from the variety of languages in the extension ecosystem

That's a big one to omit. But alright, I'll play.

It has much less packages, it's almost never used on windows, it has stopped being popular 10 years ago, it doesn't have anaconda because it's not a "corporate tech", you rarely install several versions of perl on the same system, you don't make enough projects with perl to justify one isolation per project, nobody moved to perl 6 so the all CPAN transition never had to happened, perl is not used to script DB/GIS systems/3D engines/IDE, perl is not used by millions of non coders (geographers, mathematicians, physicists, bankers, etc) that have no idea how their machine work.

But to be honest, the nail in the cofin is that distros decided not to split perl and cpan in separate packages. In fact, in somes distros, perl and cpan are already installed and ready to be used.

So for linux:

- python: you must decide among several python, then intall the right package to use pip and venv, isolate your install with venv. The procedure is different for windows. Also 2.7 is a thing.

- perl: you have one perl that hasn't change for years, no new packages, it's already installed, cpan is installed as well, and it's not gonna break your system if you use it. You don't care about windows. Perl 5 forever.

Re: Python: Please stop screwing over Linux distros

#338

Post by thereddaikon »

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.

Eh I think embedded systems are a different class. I know some people run RPis as their desktops but they are definitely the minority.

>Those are rookie numbers for a primary system

4TB suits my needs and use case fine. And tha'ts not counting my NAS.

Re: Python: Please stop screwing over Linux distros

#339

Post by drunkpotato »

nerdponx wrote: post #264
drunkpotato wrote: post #193

Earlier quoted context omitted.

pyenv is pretty good for working around this problem. I've recently switched to asdf-vm which I like even more, since it handles versions for multiple languages and tools.

I have been meaning to try out ASDF-VM. Currently my shell initialization script has at least 4 of these "version managers". While I don't really mind them (and they are mostly well-behaved), it might be nice to have something a bit more centralized.

In addition to python version issues, I was also running into JVM and gradle version compatibility issues, which I was handling with jenv and some aliases that would swap JAVAHOME environment variable as needed. asdf-vm cleaned all that up in a very clean way, and I like the way you can set .tool-versions file for a project and share with other asdf-vm users.

Re: Python: Please stop screwing over Linux distros

#340

Post by orev »

simonh wrote: post #129
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…

>Serving the needs of python developers vs. sysadmins is a false dichotomy. Python developers develop on a system that they need to admin. I couldn't disagree more. Even if the same person is admining a system they develop on, they almost certainly aren't going to admin the systems their users deploy on. The admin role and developer role should be completely separate with different goals and requirements. The system…

This is exactly the approach RHEL has taken with version 8. Typing ‘python’ results in ‘command not found’. All the system tools that use python are set to use a custom path dedicated for those tools.
Post reply on HN