Python: Please stop screwing over Linux distros

That, my friend, is called a filter bubble. And your comment is not productive btw. I for one never "fucked my environment", I only ever used distro packages and I still couldn't make a simple script even start without it spitting cryptic error messages about modules or paths.

I'm not a Python dev; I just needed to run a tool that didn't have any other alternatives.

Meanwhile, I can download scripts written in a range of other languages and just fire 1-2 commands and the thing will work.

With Python? Almost never.

> Packages go into abandonware all the time, removing version pinning doesn't fix that.

Abandoned dependencies should be treated like dropped features: re-implement them in your own code or create another library.

> Thank you for telling me this, I will be relaying to my clients that they need to upgrade their systems to newer Python versions to get new features, surely that will go well.

Very funny, but seriously they should have an upgrade path, or install their machine once and then never do a single upgrade, but again I'd say this is just tech debt piling.

> Waiting to release on new dependency versions until those versions are tested is not tech debt.

Not having your own tests is tech debt thought. I wouldn't rely on tests made by others.

> I mean, semantic versioning was done with this purpose precisely: to signal which upgrades are just bug fixes and you should upgrade ASAP

Of course I agree, the problem is that maintainers tend to not upgrade as often as they should, like until they really have too (another dependency upgrades a shared dependency). Again I see this as a maintainance problem rather than a package manager problem.

> If living at latest release works for you and dealing with dependency issues on new installations is not a problem, then go.

I'm not saying I never had a problem of course I do, I'm saying that having these problems has a better cost/benefit ratio at the end of the year, because: 0. they are smaller, dealing with one BC break at the time, and 1. they are spread over time because I integrate upstream releases continuously instead of waiting for the day I want to upgrade everything.

> "oh, it's just that this dependency released a new version that broke things and we didn't specify the version that our software needed"

I'd rather say "oh, it's just that this dependency released a new version that we are implementing support for as we speak, here's the command you can run to fix it meanwhile: ...".

But if you don't want to have that problem, just run your CI periodically, make sure the first thing you do in the morning is checking that nightly did actually pass tests, as you're talking about paid software maintenance, I'm talking about both paid and volunteer so that's why I'm including "wait for a user to report" but that doesn't apply for paid maintenance of course.

For me we're seeing the discussion between two fundamentally opposite approaches, one being defensive and the other being offensive / actual continuous integration. From my experience, the offensive strategy offers a better cost/benefit ratio at the end of the year.

If you avoid placing packages in the distribution's system Python (by using a venv) and if you aren't using some outdated distro version, your Python should be good enough. You must write backwards compatible code anyway, if your application is to last more than six months.

It is not the end of the world to be using one or even two minor versions older than the current Python version. New features must be implemented in your code and relying on bleeding edge features of your language (in production code) is outright bad design. If the core Python developers like to experiment and break their language, you are best to avoid jumping head first into that mess.

TL;DR: Keep your requirements conservative. You are not bewilden to the Python core developers, your target are your users.

Yes, Win32 API is ancient. No, it does not mean it's useless.