[TIP] Dropping Python 3.2 support for various projects
robertc at robertcollins.net
Sun Oct 25 14:31:08 PDT 2015
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.
Robert Collins <rbtcollins at hp.com>
HP Converged Cloud
More information about the testing-in-python