Pip is already seriously broken, it's just that the breakage has hit one of the main targets for the project. Part of my day job is maintaining Python for an e

Pip is already seriously broken, it's just that the breakage has hit one of the main targets for the project. Part of my day job is maintaining Python for an embedded OS. For self-evident reasons, software for the embedded OS needs to be cross compiled, and Python makes it impossible to cross-compile pip. Explicitly. Upstream's reaction is "you can't cross compile pip, you're on your own." To make matters worse, pip doesn't support non-native Python once it is built. Of course, this is just the tip of the Python portability nightmare. Python is great and completely portable as long as your target is Linux running on x86_64 or aarch64. It has second-class support for Mac OS and Windows and there are private port projects for a few other system but they generally require heavy patching. For example, the Python code violates POSIX standards in favour of assuming that everything is Linux (hey guys, time_t is not a signed integer that can be used for arbitrary arithmetic!). Executing a whole lot of system code between fork() and exec() is always broken, although it appears to mostly work on Linux as long as you disable certain kernel features, and guess which code base relies on that? Yeah. Pip is broken and now it's showing up on Debian too. Maybe it'll just get better by itself?