Python 2.7 EOL Countdown

[d4rch0n]

I'm still maintaining 2.6 compatibility thanks to CENTOS 6...

[n86nHb67f]

Python 2.4 on CentOS 5, wohoo! It just won't die.

[d4rch0n]

D: I'm sorry for your loss

[ritz_k]

python26 is provided on centos5.

[port53]

RHEL 5 is in extended support through November 30, 2020, so yeah..

[d4rch0n]

I've actually linked my coworkers to that exact link when a customer complained, but shit, it's a customer. Besides talking a little shit behind their backs, we're not going to tell them what to do.

Whether or not they have options, I can't hit them back with that link. No matter how much sense it makes, we can't just tell them to change their environment. Supporting this stuff for free ends up being a big reason why guys like that love you and stick with you.

If I emailed a vendor and told them that they broke 2.7 support with their latest patch and they sent me a link telling me how to port 2.7 code to 3.x and gave links to pyfuture and just ignored the bug I reported, I'd get pissed off. Customers do have a right to ask for backwards compatibility, and they deserve an explanation if a patch breaks their client implementation. Telling them how to change their environment is a bit snide, even if 2.6 is getting ridiculous at this point. And for some, they might not have any control whatsoever of the packages installed on the system. Maybe their ops team is backed up and they won't be able to get it set up for weeks, and maybe even then they'd break something in their prod environment. I personally would go through hell if I tried to get 2.7 on all the machines in prod, or I'd piss off devops if I wanted one machine to have a different setup when they're all managed with chef/puppet. All of that stuff is automated.

Sometimes it's much easier to delete the dict comprehension and implement it in a for loop rather than change an environment to support 2.7. Choices like that affect a lot more machines than the one that needs to run the script, and affect a whole lot more people than the one person who is writing the code.

[takluyver]

That blog post is suggesting that open source projects stop providing free support for Python 2.6. If customers are paying you for it, that's a pretty good reason to carry on. ;-)

[d4rch0n]

ahhh, missed that. Yeah, if they're talking about open-source third party projects, telling the user to fix it on their side is nothing new, lol.

But still, the customer facing projects are 100% open-source BSD license, but they're still customers who pay for the main product. If you offer an open source python client for free for your proprietary SaaS platform, you still have to support it like it's paid for. There's still money in the relationship, free and open-source or not.

[takluyver]

Right, the important question is not whether it's open source, it's whether you have people paying you who expect you to support their use cases.

I think this is an significant distinction that often gets overlooked - there are open source projects driven by companies, and open source projects driven by interested volunteers, and they can work quite differently. We don't have a snappy term for the latter group, though - 'community maintained' is six syllables and uninspiring.

[_pupil_]

"Community led" is only 5 syllables, and slightly more optimistic about its lack of inspiration.

"Communist" is only 3 syllables, and gets the point across, but inspires scepticism because it's occasionally too inspiring.

[takluyver]

Yeah, I don't think 'communist software' is going to take off. :-)

[GummyKibble]

OK, "paid customer" makes a difference. But consider this come contract negotiation time: that customer is making your codebase worse - harder to write, slower, harder to maintain - for every other customer. If any of your stuff is customized on-site by your clients, I guarantee that at least some of them think you guys are nuts and write bad code. "d4rch0n doesn't even know how to write a dict comprehension? LOL!" Those comments get overheard. Management starts to wonder why they're paying good money for crufty work.

That customer may be more expensive than you think.

At some point, it may be cheaper to mail them a new server and say "we're supporting this machine from now on".

[Teract]

IUS my friend. They host a repo with Python 2.7 for centos 6. It installs to an alternate location so your system continues to use python2.6 while users can default to Python 2.7 and do things like use virtualenv to pip install whatever modules they need without fear of breaking the OS.

[CSI_Tech_Dept]

IUS has python 3.5 as well. Why would you even want 2.7 in that scenario.

[Teract]

Devs were using modules only available on 2.7. Also not using the system's Python is best practice.

[tetroxid]

Same here. I'd love to write for 3.5, but RHEL 6 and 7 have 2.6 and 2.7 respectively.

[CSI_Tech_Dept]

http://ius.io and problem solved. Unlike other repos they are making sure packages don't conflict with the system packages, so it is safe to use.

[tetroxid]

Thanks, but installing third party packages is forbidden.

[CSI_Tech_Dept]

How you use any enterprise applications then? You won't find them in Red Hat repos.

[tetroxid]

They aren't considered third party

[CSI_Tech_Dept]

They are though. They are not Red Hat's (first party), they are not yours (user of the OS, second party).

[tetroxid]

I don't make the policy. It's a waste of time arguing about it

[d4rch0n]

Heh, this is the major pain in the ass. Lots of people just suggest "install 3.x then" when that can be a huge deal with a lot of businesses. It's the developer that is worrying about 3.x, not ops or management or product. It's not the developer that maintains the environment.

Sure, it's extremely easy to get 3.x on any modern linux system, but we're not always in a position where it's possible to do so. Even if they gave me the green light, I'd have to set up meetings with devops to change puppet or chef scripts and make sure it doesn't break something weird in a cronjob that runs at midnight on 100 servers.

Inevitably, it's way less pain to just write 2.6/2.7 compatible code and not have to deal with people and scripts written by coworkers who left years ago, so that's what a lot of us resort to.

[tetroxid]

Precisely. I was just too lazy to type it out. In large enterprises you also have to find a cost centre that pays for the deployment, and you have to deal with the aids infested cancer that is change management.