Live data from Hacker News

Python: Please stop screwing over Linux distros

drewdevault.com

241–250 of 384 posts

Re: Python: Please stop screwing over Linux distros

#241
post #56

Everyone complained, no one addressed the fact that for years the whole of python packaging was handled by like 2.5 people. But as a rant this, like most of the ‘but just fix it’ rants, fails to acknowledge the hugely diverging needs of different users. I could not live without conda, since it’s the only sane way to get a working recent geospatial stack. Others need to run embedded environments, or portable ones, som…

> Everyone complained, no one addressed the fact that for years the whole of python packaging was handled by like 2.5 people. If I can make an observation - it has nothing to do with the number of maintainers. The problem is deep, cultural and occupies a difficult space where it might be a bug or a feature. The root cause here is that the Python project, and surrounding community, have little real respect for backwar…

Python 2 was supported for 20 years. Python 2.7 (largely compatible with other Python 2 versions - and including backported changes from Python 3.1 - was supported for 12 years).

The Python project went absolutely above and beyond to support users who wanted to drag out making not particularly complex changes to their codebase for over a decade.

During this same time they improved Python 3 in response to feedback and among other effects, made it less different and easier to port, from Python 2.

Many common packages supported 2.7 up to its end-of-life as well.

One of the reasons that Python is often a source of compatibility errors is that both distros and large standalone applications embraced Python in the early 2000s, became dependent on a particular version, and then refused to work with newer versions.

Python is not responsible for all the engineering decisions everyone writing in the language has ever made.

Re: Python: Please stop screwing over Linux distros

#242

So here's a suggestion to shoot down. The biggest insight in software dependency management is that applications and libraries are different. Both have dependencies but they sit at different places in their dependency graphs. A library can be used together with other libraries and so cannot pin its own dependency versions (if all libraries did so there would conflicts everywhere) but instead can only specify constrai…

>> An application sits at the front of the dependency graph. Nothing depends on it.

In many cases, applications depend on other applications.

This can easily been seen in most Linux package management systems and also for many applications that act as more user-friendly front-ends or automation for command-line utilities.

Examples:

* Debugger front-ends

* Package management GUIs

* Multi-media processing pipelines

* Many others

Re: Python: Please stop screwing over Linux distros

#243
post #88

Earlier quoted context omitted.

This is the real legacy problem: Python comes from a world, where only one version of one packaged seemed the right way to do. I do not have a good idea, but other ecosystems evolved much more sane in the realm of packaging. While not ideal, Go has done a fairly good job - and the "module" operations are instant - which they should be.

Go is terrible for distributions to package due to the poor versioning of libraries.

go is incredible for distribution. you're distributing binaries not a bunch of source files.

now the build tooling still needs some work around versions but its only a minor problem generally as much as it annoys me personally.

Re: Python: Please stop screwing over Linux distros

#244
post #237

Earlier quoted context omitted.

> cost-per-TB There you have it: You measure in TB, not gigabytes, not megabytes. Python packages are megabytes.

Not if they pull in all of their dependencies, PyQt would have a complete copy of all Qt binaries and a complete chrome install because of course Qt includes a browser based html viewer. Python packages are gigabytes.

What distro is pulling PyQt as a dependency of Python? There is a difference between "dependency" and "every package which has the word python in the description".

Re: Python: Please stop screwing over Linux distros

#245
post #130
post #114

Earlier quoted context omitted.

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…

> That's because there is one obvious distribution of Python to use Lol, no. There is one in the Windows appstore too, which has issues with privileges. And I'm almost sure now MS ships it in some other tool too.

I wonder what percentage of the six people who use Windows app store have found that situation confusing.

Re: Python: Please stop screwing over Linux distros

#246
Linux should exert his "Linux" trademark rights by putting a representative from each of the major distros in a room, telling them to come to an agreement on a single packaging and filesystem layout for Linux, or they can no longer call their precious snowflake Linux. To me, this more than anything has hampered Linux adoption: there are too many versions of it.

Re: Python: Please stop screwing over Linux distros

#247

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…

That sounds similar to what I do in macOS. I hate installing homebrew to /usr/local so I started installing it to ~/.brew and I hate using the python from homebrew so I always use pyenv.

Re: Python: Please stop screwing over Linux distros

#248
post #237

Earlier quoted context omitted.

> cost-per-TB There you have it: You measure in TB, not gigabytes, not megabytes. Python packages are megabytes.

Not if they pull in all of their dependencies, PyQt would have a complete copy of all Qt binaries and a complete chrome install because of course Qt includes a browser based html viewer. Python packages are gigabytes.

PyQt only contains the bindings. You share the same Qt environment across your system (hence qmake needs to be in your path). The python package itself is not that big (~10 MB).

Re: Python: Please stop screwing over Linux distros

#249

I think there is an increasing trend for developers to get confused between their tools and their output. These are your tools: * pip * pip-tools * pipenv * poetry * virtualenv * venv * setuptools * pyenv * requirements.txt * etc. These are your outputs: * wheel (binary), * tarball (source). The tools in use are completely irrelevant and only add noise to the discussions around packaging. So what actually is the prob…

Python itself confuses sources and outputs in that not every package has consumable source tarballs— for some packages the only way to get static metadata on dependencies is by starting a build as if to get a binary output.

Native dependencies are not really handled except in an ad-hoc way, either.

If you want to import Python packages into a real packaging system, you are confronted with the tools whether you want to be or not.

Re: Python: Please stop screwing over Linux distros

#250

Earlier quoted context omitted.

> Manage all dependencies there Are you saying "put the different version of every dependency you need in there if you have to"? Because I don't think package managers are ready for that, they usually like to have one version installed per package.

> Because I don't think package managers are ready for that, they usually like to have one version installed per package. That's on them. Other language package managers can do it...

Exactly, the whole topic is about easing the process for Linux distro packagers right?
Post reply on HN