Drop support for Python 2.6 #1175
Conversation
|
🎉 👍 ✨ |
|
Why drop support for 2.6? Is there a blocker? |
|
I agree with @avylove; don't drop support unless there is a really compelling reason. |
This is reason enough honestly. Other than that, it is a burden to support multiple Python versions as is and dropping Python 2.6 support enables the use of a lot of nicer Python features in 2.7. Further pip, wheel and setuptools have already dropped support for 2.6.
You can still use an older version of virtualenv which supports Python 2.6. |
|
I don't think that's reason enough for a keystone module like virtualenv. This is the tool that is used to workaround those limitations in other packages. From the docs
There are a lot of developers dealing with version dependencies. I'm sure no one wants to support 2.6, but that's what the market demands. Dropping support just puts more of a burden on other people and since supporting 2.6 does not break functionality for other versions, and there is community support for it (#1170), why not just support it until there is a compelling reason? |
|
Just use an ancient version of virtualenv to go with your ancient version of Python. We’re not going to support an ancient version of Python with like 3% of the total downloads from PyPI when those people can just as easily continue to use a version that works for that Python. We’re all volunteers and taking up time dealing with 2.6 is not a productive use of our time.
…Sent from my iPhone
On Jun 2, 2018, at 7:58 PM, Avram Lubkin ***@***.***> wrote:
There are a lot of developers dealing with version dependencies. I'm sure no one wants to support 2.6, but that's what the market demands. Dropping support just puts more of a burden on other people and since supporting 2.6 does not break functionality for other versions, and there is community support for it (#1170), why not just support it until there is a compelling reason?
|
|
@dstufft why are you being condescending to someone bringing up a legit issue, and since “we’re all volunteers” and “supporting an ancient version is not productive” why are you even here? Your job as a dev is to create a tool that people can use. I honestly couldn’t give a shit less what versions you support but you don’t have to be a dick about people having concerns about you dropping support for things. |
I think you're misunderstanding the use case. I'm using Python 3.6 in my development environment and testing (with tox) for Python 2.6 through 3.7 beta. The problem is when you create a virtual environment for Python 2.6, it executes virtualenv.py with the Python 2.6 interpreter (or whatever interpreter is given). It doesn't execute the version specifically installed for 2.6.
It was almost 3% of the downloads over the last month, over 54,000. Which is even more significant given most people on RHEL/CentOS 6 are going to use the version supplied in EPEL and people like myself aren't downloading it for 2.6.
Yes, we're all volunteers. Why make it harder on other open source contributors unless there is a blocker? I have no doubt issues will come up, but other volunteers in the community will step up with pull requests as long as there is a need. |
|
@avylove tox also dropped support for Python 2.6 so your use case only works if you pin tox. Once you pin tox you can also pin virtualenv similarly. |
|
If you cannot pin virtualenv env then let's first offer a way to do it and then drop support, instead of trying to maintain an unsupported Python compatibility in the medium term. |
No description provided.