That's why Docker is a good idea for packaging things up. You basically get exactly the combination of binaries, libraries, etc. you intend to run. Probably not a bad idea to use it for development as well. Or at least something like pyenv or whatever it is called these days.

Docker saves some pain, but introduces others.

You have a container that will run anywhere, but it has a bigger attack surface and needs updates.

I also would disagree that it's easier than using virtual environments for development, and only for packaging in some narrow use cases.

They aren't too bad IMO. However, you need to set up a build environment/VM with your choice of your earliest-supported Linux+glibc. Build on old, run on new works well.

Linux backwards-compatibility is pretty good, in that a static binary should run just fine on newer systems. I've had far worse experiences with OpenBSD, where a build on an older version of the OS would never seem to run on a newer system.

> Static, portable binaries on Linux are hard.

That’s why it can’t be an afterthought. It must be baked into the language as part of the design (golang)

Why would your binary require glibc if it’s statically linked?