Python packaging targets [LWN.net]

Python packaging targets

Posted Feb 25, 2023 7:45 UTC (Sat) by cyperpunks (subscriber, #39406)
In reply to: Python packaging targets by rra
Parent article: Python packaging targets

All this is true.

The quality of software available in pypi varies a lot and some packages break compability in a random minor upgrade.

To "resolve" this owners of other projects using the project with borken compability pin version requirement to a specific version.
This is also careless, as now is any project that needs a new of version of problematic package blocked from being installed.

The reason is that Python has global name space, there can be only version of problematic package installed and this package must
be present at runtime. Python is special here. Rust or Golang can create a suitable build environment, create binaries, install and software will run forever.

Python has the worst mix of all: an easy to learn language which causes lots of low quality package to be published to repos, careless owners which break compability, even more careless owners which pin version requirements combined with globale namespace and
no different between build and runtime environment.

The future of this is not promising.

to post comments

Python packaging targets

Posted Feb 25, 2023 21:59 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

> The reason is that Python has global name space, there can be only version of problematic package installed and this package must be present at runtime. Python is special here. Rust or Golang can create a suitable build environment, create binaries, install and software will run forever.

It very much is *possible* to make hermetic builds of Python. It's just that there's so much you need to package, that you are effectively bundling an entire Python installation (like Flatpak etc.). Distros don't like this degree of vendoring, but they also have problems with Go and Rust.