I think you are missing the key point here: I don't write a ton of Python. I don't write any Python. Of course you think this is old news. You write a lot of Python. You're totally plugged in. You've known this is coming, this inside baseball is "the thing" for you. My point is that, believe it or not, the rest of the world does not keep up to date with whatever the Python community is doing. This is not unique to Python. Most people in dev community X are not aware of what is happening in dev community Y. What is unique to Python is that all of a sudden we were forced to become aware as the downstream apps began to break. By creating a backwards compatibility issue in an interpreted language, you necessarily "backload" the end-user pain to when the apps, which by definition are updated later than the code within the apps, begin to break as packages are removed from package managers, or things are EOL'ed, etc. This is a situation that I can honestly not remember happening with any other language. I can't remember any other circumstance, and certainly not one where it proceeded to happen repeatedly, where I've been abruptly made aware that utilityX was written in a no-longer-supported version of C/perl/whatever (when I previously didn't even know what language it was), after I had been running it for ages.

Also, I am not "trying hard" not to care about Python. I specifically said in my very first comment I go out of my way to avoid it now. I think that falls in the "cares" category. My default state is to not be aware of what language things are written in. I don't know if some given tool is written in C, bash, or JS. If I were to coincidentally learn what language it was written in, it might serve as a curiosity, but not really phase me either way. However, I was forced to become aware of a bunch of Python stuff since it started breaking, and then forced to learn about all the weird workarounds to get it working. Given that I was forced to repeatedly deal with dependency hell with apps in this language, I am now choosing to avoid it if I can in the future if I learn that an app is written in it.

Maybe one day you can get past DH0: http://www.paulgraham.com/disagree.html

The "magic date" when the breaking update came was 15 years ago. Python gave this developer 10 years to get with the program and update to the new version, and Debian kept it alive for an additional 5 just in case.

If a developer can't get their act together to change over their codebase to preserve minimum functionality despite FIFTEEN YEARS of warning, I don't want to be using their app because who knows what other obvious problems they are ignoring.

It’s called open source entitlement. The kind of people who fill up your issues and don’t push PRs and only donate with their melodramatic keyboard.

Nobody should ever have to be hit with obscure pip/virtualenv/pypy/etc bugs for trying to use your command line app. Nobody should have to suffer through an “installation” step that requires installing the language itself and running a language-provided package manager to install dependencies/etc. I don’t care how much you wrap it in a setup.sh that tries (and typically, fails miserably) to automate everything.

(For OS’s like linux, your distro-provided package managers make the situation slightly better, but only if you ship your app as a package using these distro’s built-in package systems, which is a huge pain if you want to support multiple distros.)

But if you opt to skip the package manager and want to ship a “simple” installation experience using something like a setup.sh, and you want to use a scripting language like python/ruby/etc (integrated with an installation of that language in $HOME or in some system directory), you’re treating your users to a world of pain. Please, please use a compiled language, and ship a binary (or collection of binaries/libraries that can sit in a folder together and just work when you run it.)

If you don't want to be banned, you're welcome to email [email protected] and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.

That was it. Since then I use Git everywhere even though I prefer Hg.

Since then I only use Ed even though I prefer MS Office. What was your point again?

(With a side dish of "I'm entitled to working tools.")

That is, I believe, the entire point of the parent, is it not? That this whole migration was not quarantined to the Python developer community. That it spilled over to users in totally unrelated spaces.

A saw still works after a decade on a shelf, programs should still work too because they are tools.

I can't think of any 100-year old software that is being used today (ha-ha).

I'm sure some airline reservation systems and banking systems written in COBOL in the 70s are still around, but they all have ongoing maintenance to keep them working correctly.

The commenter's complaint seems particularly worse with dynamic languages like JavaScript and Python than compiled things. Old projects written in node are often just as hard to get running or installed as something written in Python 2. The dependencies are out of date, you have to install an older version of Node.js, or the dependencies just don't exist anymore. And JS stuff usually generates a huge tree of dependencies even if they only directly rely on a handful of packages.

End of story, I think if these Python-2 tools/scripts were such a huge part of his project that they keep breaking builds, the company should be invest time in either rewriting them in their language of choice or maintaining those projects or a fork of those projects.

One of my old bosses was strict about this - no COMPANY projects should be relying on external package repositories, unapproved third-party dependencies, definitely not some github project maintained by only a few people. Yeah, I think if your company is relying on "requests" or some other massively popular project with tons of community maintenance, you don't want to fork that and it's important to use the standard versions. But if you're bringing in something that is used and maintained by only a few people - you either need to become part of the community that maintains it publicly or fork the project and maintain your own version.

This isn't NIH syndrome, it's basic protocol for keeping your builds reliable and dependency management simple.

Why should I, an end user, ever need to build WikidPad? I don't need to do so on Windows, why doesn't Linux support the same thing, shipping an executable?

When you go to the store, you're not presented with a set of tools for making a saw, you're given a complete, ready to go tool. Perhaps the very idea of users having to build things in Linux is the problem?

It is very similar to the problems with Windows, always pushing updates/upgrades that aren't necessary, and often break things. Windows machines are far less reliable on Wednesday than they are on Monday, because of Microsoft's idea of pushing patches on Tuesdays.

Truly a hacker news experience.

I feel your response is best summarized as: "I like Python. I've never had this problem and don't think it's a legitimate problem. Only $megacorp users have this issue, and their concerns aren't important."

If you dismiss the problem (as you've done) then you don't have to intellectually address it. The Python 2 -> 3 transition was hard for those that huge productive workloads in Python2, and this pain will have a long tail.

Whoever missed that is self responsible for all self harm done by ignoring that.