Packaging Guide - Appveyor - Remove discussion of Python 2.6?
24 views
Skip to first unread message
Paul Moore
Dec 3, 2015, 5:11:23 AM12/3/15
to pypa-dev
I've been doing some playing with Appveyor over the last couple of
days, and their Python build infrastructure is much improved. They can
now build C extensions out of the box for Python 2.7, 3.3, 3.4 and
3.5, with no config needed. (The only exceptions are 64-bit Python 3.3
and 3.4, which need some environment variables set up to use the SDK
compilers, but those compilers are present - there's no software
install needed).
They also have Python 2.6, but that's much harder to configure -
Python doesn't come with pip built in, and I don't know if the Visual
C for Python 2.7 package works with 2.6 - if not, there's a SDK setup
to do that I haven't tried out.
I'd like to revise the PUG page on Appveyor to simplify the
recommendations. The steps needed to support Appveryor are now just
adding an appveyor.yml file, plus a small batch script if you want to
support extension builds on 64-bit 3.3 and 3.4.
But I'd have to drop support for Python 2.6 in the document if I did
that. Does anyone have any objections to me doing so? Honestly,
there's basically no reason for anyone to be using 2.6 on Windows -
it's not like we have the equivalent of RHEL there needing support.
There are also some tweaks needed when testing with tox. I'd like to
put them on this page, too, and extend its scope from simply building
wheels, to "Using Appveyor for Windows support" covering testing *and*
builds. Again, before I do this does anyone have any objections?
Paul
days, and their Python build infrastructure is much improved. They can
now build C extensions out of the box for Python 2.7, 3.3, 3.4 and
3.5, with no config needed. (The only exceptions are 64-bit Python 3.3
and 3.4, which need some environment variables set up to use the SDK
compilers, but those compilers are present - there's no software
install needed).
They also have Python 2.6, but that's much harder to configure -
Python doesn't come with pip built in, and I don't know if the Visual
C for Python 2.7 package works with 2.6 - if not, there's a SDK setup
to do that I haven't tried out.
I'd like to revise the PUG page on Appveyor to simplify the
recommendations. The steps needed to support Appveryor are now just
adding an appveyor.yml file, plus a small batch script if you want to
support extension builds on 64-bit 3.3 and 3.4.
But I'd have to drop support for Python 2.6 in the document if I did
that. Does anyone have any objections to me doing so? Honestly,
there's basically no reason for anyone to be using 2.6 on Windows -
it's not like we have the equivalent of RHEL there needing support.
There are also some tweaks needed when testing with tox. I'd like to
put them on this page, too, and extend its scope from simply building
wheels, to "Using Appveyor for Windows support" covering testing *and*
builds. Again, before I do this does anyone have any objections?
Paul
Donald Stufft
Dec 3, 2015, 7:04:47 AM12/3/15
to Paul Moore, pypa-dev
then I see no reason to keep support for 2.6. I wouldn’t even bother with
support for anything other than 2.7 and like, 3.4+ or so tbh.
My 2c anyways.
-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Paul Moore
Dec 3, 2015, 8:39:33 AM12/3/15
to Donald Stufft, pypa-dev
On 3 December 2015 at 12:04, Donald Stufft <don...@stufft.io> wrote:
> If this is just for the packaging guide and not for pip/virtualenv itself
> then I see no reason to keep support for 2.6. I wouldn’t even bother with
> support for anything other than 2.7 and like, 3.4+ or so tbh.
Thanks. I've created
> If this is just for the packaging guide and not for pip/virtualenv itself
> then I see no reason to keep support for 2.6. I wouldn’t even bother with
> support for anything other than 2.7 and like, 3.4+ or so tbh.
https://github.com/pypa/python-packaging-user-guide/pull/191 if anyone
wants to comment.
Paul
Reply all
Reply to author
Forward
0 new messages