In my experience this is less to do with the fast pace of development, and more to do with the fact that many engineers use virtualenvs, and virtualenvs "vendor" the pip version so you need to update pip in each virtualenv you use. This is correct, but does lead to needing to upgrade so much.

No kidding. I pretty much don't even believe in the concept of a serious upgrade anymore, as far as pip goes anyway. As long as it still works when I run it, nobody is missing out on any serious upgrades as far as I'm concerned at this point.

That's a pretty bad mindset, new pip versions (20+) include support for binary distributions that saves a lot of time when installing pretty much anything that needs to be compiled.

Just run `pip install --upgrade pip` every month and you will be fine.

Do you have a reference for that? IIRC binary wheels have been supported for ages and not just in 20+ (which was released this year).

What the likely mean, is that newer versions of pip support newer platforms underpinning the binary packages.

Python binary packages are a bit of a kludge, they take a binary built on a base platform like CentOS 5, and use tools like patchelf to take all the libraries that they dynamically link against and re-wrap them in a new package.

Until about a year ago, CentOS 5 was the newest base platform available. So if your library needed a glibc feature or some other library feature from the past decade you were SoL.

thx - this is actually v helpful to me. yay for HN!

I'm not sure what you're talking about (pip's always done binaries for me), but I have 20.1 in any case, so...

Fully agree with this. That line has become "invisible" to my brain.

except if the command fails, then I upgrade.