Drop support for EOL Python 2.6 and 3.2#314
Conversation
|
@benjaminp We bundle six in Ansible because we need to ship it over the wire to remote hosts to run modules before we know which version of Python they are using. In Ansible, we support Python 2.6 on remote hosts, so we depend on 2.6 support in six. We also have users who use newer Python, so going forward not updating six won't be an option for us. So with this change we're stuck between a rock and a hard place. I'm not sure what the argument for dropping 2.6 support was (since 2.7 is EOL too but that still seems supported), but is there any way you would you reconsider this decision and bring it back? |
|
As the linked issue describes, as software becomes increasingly obsolete, it becomes increasingly odious to maintain the CI environments that ensures that it works. six must be one of the last projects in the world to drop 2.6 support. Core infrastructure like |
|
@benjaminp Yeah, completely understood. Unfortunately we're stuck supporting it for a while longer and there's not much we can do about that, so this puts us in a bit of a pickle outside of having to maintain our own bundled fork and backporting features. I was just hoping you might reconsider if we raised the flag on it, since this is a py2/py3 compat library. I do understand the concerns though. |
Fixes #308.
Stops testing them on the CI, update
python_requriesand remove some code specifically for those versions.Not done anything to remove any six functionality that's only a benefit on those versions, that should be in a separate PR and would be a breaking change that should ideally deprecate first.