[TIP] Dropping Python 3.2 support for various projects

[Robert Collins]

On 23 October 2015 at 21:32, Laura Creighton <lac at openend.se> wrote:
> In a message of Thu, 22 Oct 2015 23:22:36 +0200, Laura Creighton writes:

> Turns out I was mistaken.  3.3 is far from done.  There seems to be
> too little overlap between 'people who use PyPy' and 'people who use
> Python 3' to generate enough volunteers for getting later 3.x
> support into PyPy.  And there isn't enough money in the pot to
> hire somebody to do this.  Of course, the more your 3.x lags, the
> more difficult it is for 3.x users to use PyPy, so we don't expect
> a hoard of new 3.x users to decend on the place any time soon.
>
> Would it be possible to get a pinned version for PyPy only so that
> people who are testing against PyPy can continue to do so?

I don't think an externally pinned version is needed: folk can locally
do this as needed.

For instance, in project X, if you use coverage, then you'd have deps
like so for your testing:

coverage<4:python_version>="3" and python_version<"3.3"
coverage:python_version<"3" or python_version>="3.3"

And so on for any other deps when they drop 3.2 support. If that
becomes overwhelming, or project X doesn't see pypy3 as a thing they
want to directly support, then the next project downstream of X can do
the same thing in their requirements files.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud