20 versions are no joke. I can't remember the last time I used a command that wasn't install, but I suppose they are no joke!

On the other hand I would love to use the shiny new feature, but explaining it to my manager would be like talking to a tree.

> 20 versions are no joke.

Versions ≥ 18 refer to the years 2018+; they don't refer to the number of versions released anymore.

It looks version 21 (!) will remove support for Python 2.7 - now that should be interesting...

Interesting! A local company tried to hire me months ago to migrate a 2.6 legacy system to bleeding edge 2.7, I wonder if they have convinced someone yet.

I would have actually enjoyed that, the challenge being to use enough hacks and interfaces (six, __future__, etc) to make the subsequent, inevitable move to 3 a well-paid but trivial task...

You should ask to talk to a developer before accepting an obviously complicated migration. Ask about the numbers since they're not IP/Properitary. How many lines of code? How many functions? How many standard modules? How many custom libraries? Is everything Python? Are other languages being used too? That way you will know whether or not they are intentionally hiding the real issues from you to get you to do free work.

Unit test coverage ...

A bit off topic, but unit test coverage trivializes the work that goes into conducting a migration. Unit test coverage really only pertains to upgrades. A migration is not synonymous with an upgrade. Migrations are serious work that typically span entire ecosystems.

When I mentioned "the numbers" I wasn't hinting at unit test coverage. I was giving examples as to what the numbers could be. Obviously OP should ask lots of questions about all of the software running on a legacy kernel.

Were there any backwards incompatible changes in 2.7? I'm trying to remember if I even noticed when that version bump happened...

Yes, try to install it on a CentOS6 box as /usr/bin/python and suddenly no more yum etc. will work.

2.7 was essentially a bridge to Python 3. All features it has were backported from 3. This is why so many people before 2015 were saying that Python 3 doesn't provide any new features.

Release notes: http://hg.python.org/cpython/raw-file/v2.7/Misc/NEWS

TBH I think the main thing about that release, for me, was the introduction of context managers ("with"). I don't remember any particular breakage but I wasn't doing sysadmin at the time, maybe there is something in the bowels of redhat that relied on some broken behaviour...

I actually rejected it because I thought it would be extremely boring after a few days, I did that for a couple of projects when I was writing desktop apps in Python 2.x and I found it very easy (2.7 to 3.x is not especially hard either in most cases).

I never understood the point of hiring a full team for at least 6 months just for that. The only explanation I can find is that the project manager was clueless about Python.

Wait until you hear about Chrome!

;-)

In all seriousness, the constant warnings mean that users may ignore serious upgrades.

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.

I swear... it is so incredibly frustrating that I want to punch my computer when I see that message at this point. I think I had to finally shut it up via https://stackoverflow.com/a/64853362 to get my blood pressure to finally drop.

You may need to see an expert if a little warning message actually gets you that angry.

I guess exaggeration doesn't come across well over text. I was trying to get across that it's super irritating. No I don't actually want to punch my computer...