Hi,
Together with Johannes I have made a pull request for zope.publisher. Tests run on Travis in all Python versions except Python 3.2. See https://travis-ci.org/zopefoundation/zope.publisher/builds/105156787
The tests pass fine on Python3.2 on my laptop. On Travis it goes wrong while creating a virtualenv. The reason is that the pip version no longer supports 3.2. You then run into basically this error:
$ python3.2
u''
File "<stdin>", line 1 u'' ^ SyntaxError: invalid syntax
$ python3.3
u'.'
'.'
As Marius asked on the pull request (https://github.com/zopefoundation/zope.publisher/pull/10) I am raising the question: do we want to keep supporting Python 3.2 in Zope? Quoting him: "The Zope project as a whole needs to make a decision about continuing to support Python 3.2 now that large parts of the ecosystem no longer support it."
I would say we can drop it. That would mean removing py32 from the Travis/tox files.
We might want to add py35 support instead, but that needs some test updates it seems. At least for zope.publisher it works, except for two failures like this:
AssertionError: "Illegal key 'ldap/OU'" != 'Illegal key value: ldap/OU'
But we can handle py35 another time.
Am .01.2016, 14:17 Uhr, schrieb Maurits van Rees m.van.rees@zestsoftware.nl:
I would say we can drop it. That would mean removing py32 from the Travis/tox files.
+1 on that. 3.2 was an awful, hair-tearing release that should be actively discouraged.
Charlie
And IMO we should take the opportunity to drop anything below 2.7 as well.
On 27 January 2016 at 11:40, Charlie Clark < charlie.clark@clark-consulting.eu> wrote:
Am .01.2016, 14:17 Uhr, schrieb Maurits van Rees < m.van.rees@zestsoftware.nl>:
I would say we can drop it.
That would mean removing py32 from the Travis/tox files.
+1 on that. 3.2 was an awful, hair-tearing release that should be actively discouraged.
Charlie
Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
On Wed, Jan 27, 2016 at 02:17:17PM +0100, Maurits van Rees wrote:
As Marius asked on the pull request (https://github.com/zopefoundation/zope.publisher/pull/10) I am raising the question: do we want to keep supporting Python 3.2 in Zope? Quoting him: "The Zope project as a whole needs to make a decision about continuing to support Python 3.2 now that large parts of the ecosystem no longer support it."
I would say we can drop it. That would mean removing py32 from the Travis/tox files.
I'm +1 for dropping Python 3.2 support for all zopefoundation packages.
If there's consensus, I can probably do that easily with a shell oneliner -- I've all of them conveniently checked out.
Marius Gedminas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/27/2016 08:51 AM, Marius Gedminas wrote:
On Wed, Jan 27, 2016 at 02:17:17PM +0100, Maurits van Rees wrote:
As Marius asked on the pull request (https://github.com/zopefoundation/zope.publisher/pull/10) I am raising the question: do we want to keep supporting Python 3.2 in Zope? Quoting him: "The Zope project as a whole needs to make a decision about continuing to support Python 3.2 now that large parts of the ecosystem no longer support it."
I would say we can drop it. That would mean removing py32 from the Travis/tox files.
I'm +1 for dropping Python 3.2 support for all zopefoundation packages.
If there's consensus, I can probably do that easily with a shell oneliner -- I've all of them conveniently checked out.
I'd be fine with dropping 3.2 and 2.6 support entirely on them all. Required changes would include:
- - Dropping 2.6 and 3.2 from tox and travis. - - Dropping them from the Trove classifiers. - - Bumping the minor release number. - - Adding a changelog entry (with the new, targeted release number).
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
On Jan 27, 2016, at 11:40, Tres Seaver tseaver@palladion.com wrote:
I'm +1 for dropping Python 3.2 support for all zopefoundation packages.
If there's consensus, I can probably do that easily with a shell oneliner -- I've all of them conveniently checked out.
I'd be fine with dropping 3.2 and 2.6 support entirely on them all.
3.2: I know that some projects, such as BTrees, persistent and ZODB, test/work on pypy3. However, pypy3 is only released in a 3.2 compatible flavor (though it does support the u'' syntax). From hanging around on #pypy, there is some progress being made on a 3.3 compatible pypy, but I don't think there's a timeline yet. So is this proposing to drop support for pypy3 too?
2.6: Anecdotally (from comments in the github issue trackers for ZODB related projects), I know that as recently as August of last year, some zope shops still used Python 2.6 in production.
Given that, I guess I'm +0.
Thanks, Jason
Am .01.2016, 23:34 Uhr, schrieb Jason Madden jason.madden@nextthought.com:
2.6: Anecdotally (from comments in the github issue trackers for ZODB related projects), I know that as recently as August of last year, some zope shops still used Python 2.6 in production.
I've still got some sites running 2.6 as well. But you have to think about the fact that 2.6 isn't getting any of security updates any more.
Charlie
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/27/2016 05:34 PM, Jason Madden wrote:
3.2: I know that some projects, such as BTrees, persistent and ZODB, test/work on pypy3. However, pypy3 is only released in a 3.2 compatible flavor (though it does support the u'' syntax). From hanging around on #pypy, there is some progress being made on a 3.3 compatible pypy, but I don't think there's a timeline yet. So is this proposing to drop support for pypy3 too?
Not directly: we would leave it in as tested, but could clean up all the stupid workarounds for missing unicode literals (a disastrous example of allowing purity to defeat practicality). If other changes broke only on pypy3, that would be a reason to leave their workarounds in place until it supports the 3.3 stdlib.
2.6: Anecdotally (from comments in the github issue trackers for ZODB related projects), I know that as recently as August of last year, some zope shops still used Python 2.6 in production.
I'll let Nich Coghlan's answer speak for me on this one:
http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.htm l
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
On Wed, Jan 27, 2016 at 12:40:52PM -0500, Tres Seaver wrote:
On 01/27/2016 08:51 AM, Marius Gedminas wrote:
On Wed, Jan 27, 2016 at 02:17:17PM +0100, Maurits van Rees wrote:
As Marius asked on the pull request (https://github.com/zopefoundation/zope.publisher/pull/10) I am raising the question: do we want to keep supporting Python 3.2 in Zope? Quoting him: "The Zope project as a whole needs to make a decision about continuing to support Python 3.2 now that large parts of the ecosystem no longer support it."
I would say we can drop it. That would mean removing py32 from the Travis/tox files.
I'm +1 for dropping Python 3.2 support for all zopefoundation packages.
If there's consensus, I can probably do that easily with a shell oneliner -- I've all of them conveniently checked out.
I'd be fine with dropping 3.2 and 2.6 support entirely on them all. Required changes would include:
- Dropping 2.6 and 3.2 from tox and travis.
- Dropping them from the Trove classifiers.
- Bumping the minor release number.
- Adding a changelog entry (with the new, targeted release number).
Bumping version numbers and adding changelog entries are a bit beyond my shell-fu, and I retract my offer for a mass change.
Marius Gedminas
Op 28/01/16 om 07:28 schreef Marius Gedminas:
On Wed, Jan 27, 2016 at 12:40:52PM -0500, Tres Seaver wrote:
On 01/27/2016 08:51 AM, Marius Gedminas wrote:
On Wed, Jan 27, 2016 at 02:17:17PM +0100, Maurits van Rees wrote:
As Marius asked on the pull request (https://github.com/zopefoundation/zope.publisher/pull/10) I am raising the question: do we want to keep supporting Python 3.2 in Zope? Quoting him: "The Zope project as a whole needs to make a decision about continuing to support Python 3.2 now that large parts of the ecosystem no longer support it."
I would say we can drop it. That would mean removing py32 from the Travis/tox files.
I'm +1 for dropping Python 3.2 support for all zopefoundation packages.
If there's consensus, I can probably do that easily with a shell oneliner -- I've all of them conveniently checked out.
I'd be fine with dropping 3.2 and 2.6 support entirely on them all. Required changes would include:
- Dropping 2.6 and 3.2 from tox and travis.
- Dropping them from the Trove classifiers.
- Bumping the minor release number.
- Adding a changelog entry (with the new, targeted release number).
Bumping version numbers and adding changelog entries are a bit beyond my shell-fu, and I retract my offer for a mass change.
Removing the Trove classifiers can be done with this shell script:
#!/bin/sh # Remove Python 2.6 and 3.2 classifiers (and lower) from setup.py. cat setup.py | grep -v 'Programming Language :: Python :: 2.3' | grep -v 'Programming Language :: Python :: 2.4' | grep -v 'Programming Language :: Python :: 2.5' | grep -v 'Programming Language :: Python :: 2.6' | grep -v 'Programming Language :: Python :: 3.0' | grep -v 'Programming Language :: Python :: 3.1' | grep -v 'Programming Language :: Python :: 3.2' > setup.py.tmp mv setup.py.tmp setup.py git diff setup.py echo "Commit this? [ENTER means yes, anything else means revert] " read answer if test "x$answer" == 'x'; then echo "committing" git commit setup.py -m "Removed Python 2.6 and 3.2 classifiers (and lower)." else echo "Reverting setup.py." git checkout -- setup.py fi
I am looking if I can create a new command in zest.releaser to add a changelog entry that you pass on the command line.
Bumping versions: can be easily done with zest.releaser when doing a release. But if you are not yet creating a release and only want to update the development version, this cannot be done yet. I might be able to add that too. Normally not too useful, but in batch it can be handy.
Op 28/01/16 om 12:42 schreef Maurits van Rees:
I am looking if I can create a new command in zest.releaser to add a changelog entry that you pass on the command line.
Bumping versions: can be easily done with zest.releaser when doing a release. But if you are not yet creating a release and only want to update the development version, this cannot be done yet. I might be able to add that too. Normally not too useful, but in batch it can be handy.
I have released zest.releaser 6.6.0 with two new commands: addchangelogentry and bumpversion. Sample usage:
$ addchangelogentry "Removed Python 3.2 classifier." $ bumpversion --feature
Possibly add --no-input to accept the defaults.
Greetings from the Plone Alpine City Sprint in Innsbruck, Austria!
-
Charlie Clark -
Jason Madden -
Leonardo Rochael Almeida -
Marius Gedminas -
Maurits van Rees -
Tres Seaver