drop 2.6 support?

[njsmith]

Apparently the last rebuild broke 2.6 support, because it picked up the latest version of pip, and the latest version of pip dropped 2.6 support: #125

(Or something like that, I haven't looked in detail.)

Should we fix it, or drop 2.6 support entirely? Right now I guess we're building and shipping a 2.6 build that doesn't actually work...

Relevant post from 2.5 years ago: http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html

CC @matthew-brett

[jamadden]

gevent dropped 2.6 support a year ago, so we no longer need manylinux to support it. The same goes for other libs with C extensions I work on like zope.interface.

[rdb]

For what it's worth, I can confirm we have no compelling reason to support 2.6 either. Python 2.6 stopped being maintained in 2013, and given that pip, wheel and setuptools finally dropped 2.6 support, continuing to support it in manylinux seems like a pointless endeavour.

[dvarrazzo]

Psycopg 2.7.x still support Python 2.6. Because psycopg release policy follows semver, we are not planning to drop Python 2.6 support until Psycopg 2.8. So please allow a way to install a manylinux image which can still support Python 2.6 (a Docker tag, whatever).

Also note that wheel 0.30 also dropped support for Python 3.2 and 3.3: they appear to be still working, as far as Psycopg is concerned, but this is possibly just luck. I suggest to build the image using wheel<0.30 for the above Python versions.

[njsmith]

@dvarrazzo when is psycopg 2.8 expected to release? (Or maybe what I really mean is: when do you plan to drop support for psycopg 2.7.x?)

The manylinux images don't currently support Python 3.2. I guess we could consider dropping 3.3 at some point too -- my guess is it has substantially lower usage than 2.6, though I haven't checked...

[hugovk]

I'd like to suggest Psycopg drop Python 2.6 sooner rather than later (eg. the next release). Python 2.6 hasn't received security updates in 4 years, and many other libraries have already dropped it, with more in the process, making it harder to support (as you've discovered with wheel), and some are already planning on dropping 2.7 in mid-2018.

Here's the pip installs for psycopg2 from PyPI for the last month (via pypinfo --percent --pip psycopg2 pyversion), showing a very small fraction for 2.6.

python_version	percent	download_count
2.7	66.3%	1,204,104
3.6	16.2%	295,175
3.5	10.5%	190,975
3.4	6.0%	108,275
2.6	0.8%	15,099
3.7	0.1%	1,774
3.3	0.1%	1,147
3.2	0.0%	25
None	0.0%	21

I've opened an issue here: psycopg/psycopg2#626.

[dvarrazzo]

@njsmith I don't say to keep on supporting 2.6: I just say leave open the possibility to use an older image to build it.

We don't have a scheduled date to release 2.8. If the wheel infrastructure won't be available anymore before that time we will simply drop 2.6 wheels in some Psycopg 2.7.x. I'm not overly fussed with 2.6 wheels, no (psycopg wheels are recent, less than 1 year old: I doubt anyone relies on them while requiring Python 2.6...)

I just expect, because it's the most natural thing in the world, that manylinux images provide some form of semantic versioning to identify the supported features... no?

[hugovk]

Note: psycopg2 has dropped support for EOL Pythons 2.6 and 3.3 (psycopg/psycopg2#628).

[ghost]

Guys, would it be OK for multibuild to drop Python 2.6?

[dvarrazzo]

No, psycopg _will_ drop support for Python 2.6 in the next major release (2.8). If I can I will release wheels in the next 2.7. If you make my life impossible of course I won't, but my preference would be to not change behaviour in a bugfix release, so having wheels disappear between 2.7.3 and 2.7.4 is totally not ideal for me. On 30 Nov 2017 21:42, "Hugo" <[email protected]> wrote: Note: psycopg2 has dropped support for EOL Pythons 2.6 and 3.3 ( psycopg/psycopg2#628 <psycopg/psycopg2#628>).

[ghost]

I'm pretty sure that #127 would make life impossible. Actually, life may already be impossible given that the 2.6 image appears to be currently broken.