Hi everyone, what is the process to start working on ZTK 2.0? We are about 5-6 packages away from porting ZTK to Python 3 and I would like to start working on a new release. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
Hi. The process for a ZTK 2.0 release isn't really well defined. I'm not sure if Jan-Wijbrand and Christophe are still interested in working on ZTK releases. Contrary to wait I said before I'd be willing to work on a ZTK 2.0 release (knowing the tools and procedure). My goals for a 2.0 release would be (comparing to http://docs.zope.org/zopetoolkit/releases/overview-1.1.html): - Drop support for Python 2.5 (ZTK 1.1 still supports that) - Add support for Python 3.x (either 3.3 or 3.2 and 3.3) - Drop all zope.app packages from the KGS (most were deprecated in ZTK 1.1) - Update to buildout 2 - Update to ZODB 4 Hanno On Tue, Feb 26, 2013 at 4:45 PM, Stephan Richter <stephan.richter@gmail.com> wrote:
Hi everyone,
what is the process to start working on ZTK 2.0? We are about 5-6 packages away from porting ZTK to Python 3 and I would like to start working on a new release.
Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" _______________________________________________ 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 )
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/26/2013 11:04 AM, Hanno Schlichting wrote:
My goals for a 2.0 release would be (comparing to http://docs.zope.org/zopetoolkit/releases/overview-1.1.html):
- Drop support for Python 2.5 (ZTK 1.1 still supports that)
+1.
- Add support for Python 3.x (either 3.3 or 3.2 and 3.3)
I would prefer 3.2 and 3.3. The major hurdle for 3.2-compatibility is unicode literals: I volunteer to do the work if needed to fix that up for the 3.3-ported packages.
- Drop all zope.app packages from the KGS (most were deprecated in ZTK 1.1)
+sys.maxint
- Update to buildout 2 - Update to ZODB 4
+1 to both. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEs7IoACgkQ+gerLs4ltQ5zCACfbHYVhZES9b6BBnj/OKLytaNu MToAnAyA//okvxRZdWrDL5XxgTBA7GSQ =2JJu -----END PGP SIGNATURE-----
On Tuesday, February 26, 2013 05:04:26 PM Hanno Schlichting wrote:
Contrary to wait I said before I'd be willing to work on a ZTK 2.0 release (knowing the tools and procedure).
Could you outline what the first step would be to create an alpha release list for 2.0? We could manually include an sdist of the ZODB 4 py3 branch to make the tests pass under Python 3. Is anyone here willing to start a buildbot using Python 3.3 to test the ZTK?
My goals for a 2.0 release would be (comparing to http://docs.zope.org/zopetoolkit/releases/overview-1.1.html):
Great!
- Drop support for Python 2.5 (ZTK 1.1 still supports that)
Yeah, none of the 4.0 packages do.
- Add support for Python 3.x (either 3.3 or 3.2 and 3.3)
Since I was unwilling to change all u'...' to u('...'), most packages currently only have Python 3.3 support. By the time ZTK 2.0 will be released, I think most people will have switched to Python 3.3.
- Drop all zope.app packages from the KGS (most were deprecated in ZTK 1.1)
Some of the zope.app packages (the ones not deprecated) should stay or simply be renamed to not being called zope.app.*.
- Update to buildout 2
Yep, already done for all 4.0 packages.
- Update to ZODB 4
This will be a requirement for Py3 support or is anyone willing to backport all the changes to ZODB3? :-) We will also need to add a few packages, such as BTrees, persistent, transaction, etc. and deprecate/remove some others like zope.broken, zope.untrustedpython, zope.fixers, and zope.apidoc. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
On Tue, Feb 26, 2013 at 6:12 PM, Stephan Richter <stephan.richter@gmail.com> wrote:
Could you outline what the first step would be to create an alpha release list for 2.0? We could manually include an sdist of the ZODB 4 py3 branch to make the tests pass under Python 3.
I'll have to look at the procedure again a bit. Will do so in the next days and start updating svn.zope.org/repos/main/zopetoolkit/trunk
- Drop all zope.app packages from the KGS (most were deprecated in ZTK 1.1)
Some of the zope.app packages (the ones not deprecated) should stay or simply be renamed to not being called zope.app.*.
Our rule for inclusion in the ZTK is: Whatever library is used by at least two out of the three frameworks (BlueBream, Grok, Zope). Given that BlueBream hasn't seen any release beyond a 1.0 about two years back, I'm not sure it's active or relevant anymore. Grok isn't seeing frequent releases, but there was a 1.5.5 mid last year. If you compare the version list from the last ZTK 1.1.5 (http://download.zope.org/zopetoolkit/index/1.1.5/zopeapp-versions.cfg) and Grok 1.5.5 (http://grok.zope.org/releaseinfo/1.5.5/versions.cfg), you'll notice that Grok already overwrites the version requirement for half of the non-deprecated packages with its own versions. And as I said, Zope isn't using any of them anymore for a long time. So I don't see any value in testing and promising stability for those zope.app packages, when there aren't any shared consumers for the specific versions. And the actually used versions by Grok are: zope.app.applicationcontrol, zope.app.appsetup, zope.app.debug - renaming those to a non zope.app prefix doesn't make a lot of sense for me either - as they are all about a specific app server configuration and not generally reusable libraries. Hanno
Hi, On 2/26/13 7:26 PM, Hanno Schlichting wrote: snip
Our rule for inclusion in the ZTK is: Whatever library is used by at least two out of the three frameworks (BlueBream, Grok, Zope).
Given that BlueBream hasn't seen any release beyond a 1.0 about two years back, I'm not sure it's active or relevant anymore. Grok isn't seeing frequent releases, but there was a 1.5.5 mid last year.
If you compare the version list from the last ZTK 1.1.5 (http://download.zope.org/zopetoolkit/index/1.1.5/zopeapp-versions.cfg) and Grok 1.5.5 (http://grok.zope.org/releaseinfo/1.5.5/versions.cfg), you'll notice that Grok already overwrites the version requirement for half of the non-deprecated packages with its own versions. And as I said, Zope isn't using any of them anymore for a long time.
So I don't see any value in testing and promising stability for those zope.app packages, when there aren't any shared consumers for the specific versions.
And the actually used versions by Grok are: zope.app.applicationcontrol, zope.app.appsetup, zope.app.debug - renaming those to a non zope.app prefix doesn't make a lot of sense for me either - as they are all about a specific app server configuration and not generally reusable libraries.
Agreed, from a Grok perspective: if there is no shared interested anymore in the zope.app.* packages, Grok will need to take up maintainership for those itself. In a way we already did by upping the versions of several of those package already. The zope.app.* packages that really are in use for a vanilla Grok-based application are zope.app.applicationcontrol, zope.app.appsetup and zope.app.debug and zope.app.wsgi. If there would be a strong drive from the Grok community to have Python 3 compatibility, they (and that includes me :) ) should port those zope.app.* packages or build the equivalents. I'll make note of this on the Grok dev list as well. regards, jw
On Tue, Feb 26, 2013 at 12:12 PM, Stephan Richter <stephan.richter@gmail.com> wrote:
Is anyone here willing to start a buildbot using Python 3.3 to test the ZTK?
I created a buildbot (the 1.1 branch) two months ago[1]: http://buildbot.afpy.org/ztk1.1dev/builders/Python3.3.0%20Linux%2064bit Ready to launch a new one with ZTK 1.2 / 2.0 / whatever. In the same time, i test regularly the Zope3 packages in my own way[2] (testing with mr.developer is cool but I want to test "official" packages on the PyPI) . A bit hard 'cause: 1. Some essential packages are broken (ZODB, zope.app.wsgi, zope.index). It's a pain to "simulate" the missing packages. 2. z3c.recipe.compattest and zc.recipe.testrunner doesn't work with Buildout 2.
- Add support for Python 3.x (either 3.3 or 3.2 and 3.3)
Since I was unwilling to change all u'...' to u('...'), most packages currently only have Python 3.3 support. By the time ZTK 2.0 will be released, I think most people will have switched to Python 3.3.
+1
- Drop all zope.app packages from the KGS (most were deprecated in ZTK 1.1)
Some of the zope.app packages (the ones not deprecated) should stay or simply be renamed to not being called zope.app.*.
All? In my mind, some zope.app are essentials like zope.app.wsgi, zope.app.appsetup or zope.app.testing.
We will also need to add a few packages, such as BTrees, persistent, transaction, etc. and deprecate/remove some others like zope.broken, zope.untrustedpython, zope.fixers, and zope.apidoc.
Can you tell me what is missing or deprecated in this list ? https://github.com/sdouche/zopetoolkit-py3.3/blob/master/ztk.cfg [1] https://mail.zope.org/pipermail/zope-dev/2012-December/044964.html [2] https://github.com/sdouche/zopetoolkit-py3.3 -- Sebastien Douche <sdouche@gmail.com> Twitter: @sdouche / G+: +sdouche
On Wed, Feb 27, 2013 at 11:04:46AM -0500, Sebastien Douche wrote:
2. z3c.recipe.compattest and zc.recipe.testrunner doesn't work with Buildout 2.
The latter has been fixed in zc.recipe.testrunner 2.0.0. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
On Wed, Feb 27, 2013 at 5:04 PM, Sebastien Douche <sdouche@gmail.com> wrote:
2. z3c.recipe.compattest and zc.recipe.testrunner doesn't work with Buildout 2.
Both do now. You currently need z3c.recipe.compattest from trunk though. I updated the ZTK trunk in the last days, and most of it should work under Python 3.3 now. To test do: svn co svn://svn.zope.org/repos/main/zopetoolkit/trunk ztk-trunk cd ztk-trunk python3.3 bootstrap.py bin/buildout bin/test-ztk Locally I get test failures for 10 packages - since not all are ported yet. But the overall buildout and test infrastructure works. Note that this is pulling in ZODB, ZEO and the compattest recipe from Git/SVN via mr.developers auto-checkout option. For everything else it uses (alpha) releases. If you want to test the master of every package, you have to run "bin/buildout -c development.cfg".
Can you tell me what is missing or deprecated in this list ? https://github.com/sdouche/zopetoolkit-py3.3/blob/master/ztk.cfg
Best check back against the canonical file in SVN as mentioned above. Hanno
Hi, On 2/26/13 5:04 PM, Hanno Schlichting wrote:
Hi.
The process for a ZTK 2.0 release isn't really well defined. I'm not sure if Jan-Wijbrand and Christophe are still interested in working on ZTK releases.
I'm personally and from a business-perspective still interested in the ZTK and to have Grok to be a relevant (to the ZTK process) "consumer" of the ZTK. That said, I've been off of the radar for a while concerning the ZTK because: 1) busy and 2) Grok's proven to be fairly stable and thus did not need much maintenance for quite a while. So: * Thanks Stephan and Hanno to get this ball rolling again * Thanks to whoever ported so many of the ZTK packages to Python 3 already! * I'll need to blow of some dust from my ZTK-knowledge and how Grok is using it to give you useful input to your questions. regards, jw
participants (7)
-
Hanno Schlichting -
Jan-Wijbrand Kolman -
Lennart Regebro -
Marius Gedminas -
Sebastien Douche -
Stephan Richter -
Tres Seaver