Re: [Zope-dev] Avoid deprecation warnings in the testrunner
On Tue, Dec 29, 2009 at 07:38:16AM +0100, Fabio Tranchitella wrote: * 2009-12-28 13:31, Marius Gedminas wrote: I think you mean assumes doctest is imported in zope.testing's __init__.py. There's no difference between modules or packages for the import statement, witness Yes, you are right; any comment on my patches though? I'd love to release a zope.testing which emits a single *useless* deprecation warning. Uh, what? Don't you mean doesn't? Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ 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 )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Mon Dec 28 12:00:00 2009 UTC to Tue Dec 29 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Mon Dec 28 20:55:03 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013281.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Dec 28 20:57:03 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013282.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Mon Dec 28 20:59:03 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013283.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Dec 28 21:01:03 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013284.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Mon Dec 28 21:03:03 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013285.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Dec 28 21:05:03 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013286.html ___ 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 )
[Zope-dev] Top-level namespace package for Zope 2 ?
Hi, I was going through Zope 2 source code today. There are 20+ top-level packages specific to Zope 2. Would it be useful if we move those packages to a top-level namespace package. I mean something similar to: zope.app.*, grokcore.*, repoze.bfg.* ? Well, I don't have any name suggestion :) Regards, Baiju M ___ 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 )
Re: [Zope-dev] Top-level namespace package for Zope 2 ?
On Tue, Dec 29, 2009 at 6:40 PM, Baiju M mba...@zeomega.com wrote: Hi, I was going through Zope 2 source code today. There are 20+ top-level packages specific to Zope 2. Would it be useful if we move those packages to a top-level namespace package. I mean something similar to: zope.app.*, grokcore.*, repoze.bfg.* ? One more example: plone.app. Regards, Baiju M ___ 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 )
Re: [Zope-dev] Top-level namespace package for Zope 2 ?
On Tue, Dec 29, 2009 at 2:10 PM, Baiju M mba...@zeomega.com wrote: I was going through Zope 2 source code today. There are 20+ top-level packages specific to Zope 2. Would it be useful if we move those packages to a top-level namespace package. I mean something similar to: zope.app.*, grokcore.*, repoze.bfg.* ? What would be the advantage of that? It'd break every single existing import. Most of those packages aren't reusable in the wild and shouldn't be released outside of the Zope2 distribution. The packages that we might want to break out (like we did with Acquistion, ExtensionClass, DateTime) should retain their name, so nobody has to change any code to work with them. Hanno ___ 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 )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
Hey, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hanno Schlichting wrote: The ZTK no longer contains any zope.app packages with one exception. I'm not sure I understand the details of what you did. I think we should be careful to just remove the zope.app packages from the ZTK entirely. I.e. we should maintain the versions of the zope.app.* packages that were in Zope 3.4 (or at least the original Zope 3 tree) in the ZTK for the time being. Otherwise we make people's life rather difficult. zope.app packages are still out there, but no longer part of the ZTK after Hanno's work: he has squished (or tricked others into doing it) all remaining dependencies within the ZTK packages on zope.app.*. I'm +sys.maxint on this change. I'm very aware of Hanno's efforts and I'm very happy with it, but a lot of people contributed to making this possible. The goal is a clean dependency tree, and removing zope.app.* is a sub-goal that a clean dependency tree makes possible. We can't be making peoples' life difficult by removing zope.app.* from the ZTK, because *nobody has shipped code* which depends on the ZTK per se. Anybody with dependencies on those packages needs to extend their own configuration to include them. Hanno has been doing *more* grenade smothering by helping finish zope.app eradication in Zope2, as well. CMF is nearly zope.app free (one remaining testing dependency). We have tons of code that needs to upgrade to the ZTK, as the ZTK is derived from Zope 3. Zope 3 contained a lot of extra packages and we've been shipping code of the exploded Zope 3 for a while. Take for instance upgrading an existing Grok-based app. While I'd like zope.app* to be removed as much as possible from those applications, we'll need to at least provide a compatibility set for a while. My idea is to maintain versions of the zope.app.* packages that are known to work together and work with the zope.* packages for the time being. If we don't maintain a set of versions that work together, we risk breaking things. It seems to be the route to least effort to do this maintenance in a special sub-category of the ZTK. At present time I know the steering group certainly doesn't have consensus on removing zope.app.*. I know Jim for one was quite adamant that zope.app.* remain part of the ZTK for the time being (unfortunately one discussion that I neglected to record in the ZTK decisions document). We can't just go and throw these out without a clear decision. Regards, Martijn ___ 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 )
[Zope-dev] Zope 2.12.2 SyntaxError on installation
Following the guide at
http://docs.zope.org/zope2/releases/2.12/INSTALL.html#buildout-instances
I get the following error:
m...@platonas:~/src/akl-website-z2.12-experiment $ python2.5 bootstrap.py
Creating directory '/home/mg/src/akl-website-z2.12-experiment/bin'.
Creating directory '/home/mg/src/akl-website-z2.12-experiment/parts'.
Creating directory '/home/mg/src/akl-website-z2.12-experiment/develop-eggs'.
Generated script '/home/mg/src/akl-website-z2.12-experiment/bin/buildout'.
m...@platonas:~/src/akl-website-z2.12-experiment $ time bin/buildout
Upgraded:
zc.buildout version 1.4.3,
setuptools version 0.6c11;
restarting.
Generated script '/home/mg/src/akl-website-z2.12-experiment/bin/buildout'.
Installing instance.
Getting distribution for 'Zope2'.
src/AccessControl/cAccessControl.c:598: warning: ‘intargfunc’ is deprecated
src/AccessControl/cAccessControl.c:599: warning: ‘intargfunc’ is deprecated
src/AccessControl/cAccessControl.c:600: warning: ‘intintargfunc’ is deprecated
src/AccessControl/cAccessControl.c:606: warning: ‘intargfunc’ is deprecated
src/Record/_Record.c:340: warning: ‘intargfunc’ is deprecated
src/Record/_Record.c:341: warning: ‘intargfunc’ is deprecated
src/Record/_Record.c:342: warning: ‘intintargfunc’ is deprecated
File build/bdist.linux-i686/egg/Zope2/utilities/load_site.py, line 248
body = (htmlheadtitledtml-var title_or_id/title
^
SyntaxError: EOL while scanning single-quoted string
File
/home/mg/tmp/buildout-eggs/tmprWUwxL/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/utilities/load_site.py,
line 248
body = (htmlheadtitledtml-var title_or_id/title
^
SyntaxError: EOL while scanning single-quoted string
Got Zope2 2.12.2.
which seems to be https://bugs.launchpad.net/zope2/+bug/501265
Then buildout proceeds as if nothing is wrong.
Getting distribution for 'zope.app.publication==3.7.0'.
Got zope.app.publication 3.7.0.
Getting distribution for 'zope.app.form==3.8.1'.
Got zope.app.form 3.8.1.
Getting distribution for 'zope.viewlet==3.5.0'.
Got zope.viewlet 3.5.0.
Getting distribution for 'zope.contentprovider==3.5.0'.
Got zope.contentprovider 3.5.0.
Getting distribution for 'zope.component==3.7.1'.
Got zope.component 3.7.1.
Getting distribution for 'zLOG==2.11.1'.
Got zLOG 2.11.1.
Getting distribution for 'tempstorage==2.11.2'.
Got tempstorage 2.11.2.
Getting distribution for 'Persistence==2.11.1'.
Got Persistence 2.11.1.
Getting distribution for 'ExtensionClass==2.11.3'.
Got ExtensionClass 2.11.3.
Getting distribution for 'DateTime==2.12.0'.
Got DateTime 2.12.0.
Getting distribution for 'Acquisition==2.12.4'.
Got Acquisition 2.12.4.
Getting distribution for 'zope.app.testing==3.6.2'.
Got zope.app.testing 3.6.2.
Getting distribution for 'zope.app.appsetup==3.11'.
Got zope.app.appsetup 3.11.
Generated script '/home/mg/src/akl-website-z2.12-experiment/bin/runzope'.
Generated script '/home/mg/src/akl-website-z2.12-experiment/bin/zopectl'.
Generated interpreter '/home/mg/src/akl-website-z2.12-experiment/bin/py'.
After that, it refuses to create a Data.fs and start up:
m...@platonas:~/src/akl-website-z2.12-experiment $ bin/runzope
Traceback (most recent call last):
File bin/runzope, line 93, in module
Zope2.Startup.run.run()
File
/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/Startup/run.py,
line 21, in run
starter.prepare()
File
/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/Startup/__init__.py,
line 87, in prepare
self.startZope()
File
/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/Startup/__init__.py,
line 264, in startZope
Zope2.startup()
File
/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/__init__.py,
line 47, in startup
_startup()
File
/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/App/startup.py,
line 72, in startup
DB = dbtab.getDatabase('/', is_root=1)
File
/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/Startup/datatypes.py,
line 283, in getDatabase
name = self.getName(mount_path)
File
/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/Startup/datatypes.py,
line 300, in getName
self._mountPathError(mount_path)
File
/home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/Startup/datatypes.py,
line 273, in _mountPathError
No root database configured)
ZConfig.ConfigurationError: No root database configured
Huh? Result of that load_site.py error, or a missing manual step that I should
have known to do despite it being not mentioned in the installation docs?
I was brave enough to specify INSTANCEHOME as '.' in my zope.conf,
because I strongly believe hardcoding absolute
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
Hanno Schlichting wrote: On Mon, Dec 28, 2009 at 10:57 PM, Martijn Faassen faas...@startifact.com wrote: Hanno Schlichting wrote: The ZTK no longer contains any zope.app packages. I think we should be careful to just remove the zope.app packages from the ZTK entirely. I.e. we should maintain the versions of the zope.app.* packages that were in Zope 3.4 (or at least the original Zope 3 tree) in the ZTK for the time being. Otherwise we make people's life rather difficult. I disagree. In my opinion it's not part of the job of the ZTK to provide backwards compatibility with Zope 3. The toolkit is not a replacement for all of Zope 3 and you cannot run a Zope 3 application even after following all the refactorings on the toolkit alone. If users of Zope 3 want an upgrade story, they need to get together and make a new Zope 3 release which is based on the ZTK. Totally ignoring our community's responsibility towards backwards compatibility and delegating it to a mythical set of Zope 3 maintainers isn't an option at all. We need to provide an upgrade path from pre-ZTK applications to ZTK applications. This upgrade path can take the form of a set of versions of zope.app.* libraries that people can choose to install for backwards compatibility. We should maintain this set of versions as part of the ZTK's test regime at the very least, otherwise we'll inevitably break something. For Zope2 we have covered the upgrade story already. Zope 2.12 uses its own KGS, which includes the entire set of zope.app packages in compatible versions. Let's please please please maintain that set of zope.app.* packages centrally. Zope 2 isn't the only consumer of these packages. On a more practical note, it's actually just not helpful to include version pins for any zope.app packages in the ztk.cfg. I can add any arbitrary set of version definitions there. Then run the test-ztk tests and all tests will always pass. Since the packages under tests don't include nor depend on any zope.app packages, their test result is independent of any zope.app version pins. Then we certainly need to do more than version pins. We also need to test these packages. -1 to this change. I'm going to add the zope.app.* packages back to the ZTK until we've had a proper discussion about how, as a Zope community, we go forward with this. Delegating this responsibility *separately* to sub projects is just plain silly. Regards, Martijn ___ 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 )
Re: [Zope-dev] Zope 2.12.2 SyntaxError on installation
2009/12/29 Marius Gedminas mar...@gedmin.as: I get the following error: File build/bdist.linux-i686/egg/Zope2/utilities/load_site.py, line 248 body = (htmlheadtitledtml-var title_or_id/title ^ SyntaxError: EOL while scanning single-quoted string File /home/mg/tmp/buildout-eggs/tmprWUwxL/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/utilities/load_site.py, line 248 body = (htmlheadtitledtml-var title_or_id/title ^ SyntaxError: EOL while scanning single-quoted string I already fixed that error on the 2.12 branch. But it's a bogus message generated by setuptools. It tries to compile all scripts ending in .py when building the egg. The script in question is never used anywhere and is probably some bitrot. After that, it refuses to create a Data.fs and start up: File /home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/Startup/datatypes.py, line 273, in _mountPathError No root database configured) ZConfig.ConfigurationError: No root database configured Huh? Result of that load_site.py error, or a missing manual step that I should have known to do despite it being not mentioned in the installation docs? I was brave enough to specify INSTANCEHOME as '.' in my zope.conf, because I strongly believe hardcoding absolute paths is dumb. �...@platonas:~/src/akl-website-z2.12-experiment $ cat etc/zope.conf %define INSTANCE . python $INSTANCE/bin/py instancehome $INSTANCE Well. You didn't specify a database file in your zope,conf it seems. Without a declaration, there's no database. Hanno ___ 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 )
Re: [Zope-dev] Zope 2.12.2 SyntaxError on installation
On Tue, Dec 29, 2009 at 03:30:20PM +0100, Hanno Schlichting wrote: 2009/12/29 Marius Gedminas mar...@gedmin.as: I get the following error: File build/bdist.linux-i686/egg/Zope2/utilities/load_site.py, line 248 body = (htmlheadtitledtml-var title_or_id/title ^ SyntaxError: EOL while scanning single-quoted string I already fixed that error on the 2.12 branch. But it's a bogus message generated by setuptools. It tries to compile all scripts ending in .py when building the egg. The script in question is never used anywhere and is probably some bitrot. Ah, I thought it was something like this. After that, it refuses to create a Data.fs and start up: File /home/mg/tmp/buildout-eggs/Zope2-2.12.2-py2.5-linux-i686.egg/Zope2/Startup/datatypes.py, line 273, in _mountPathError No root database configured) ZConfig.ConfigurationError: No root database configured Huh? Result of that load_site.py error, or a missing manual step that I should have known to do despite it being not mentioned in the installation docs? I was brave enough to specify INSTANCEHOME as '.' in my zope.conf, because I strongly believe hardcoding absolute paths is dumb. �...@platonas:~/src/akl-website-z2.12-experiment $ cat etc/zope.conf %define INSTANCE . python $INSTANCE/bin/py instancehome $INSTANCE Well. You didn't specify a database file in your zope,conf it seems. Without a declaration, there's no database. Makes sense, in a rather user-unfriendly way. May I suggest the documentation be amended to supply a closer-to-working zope.conf? I'm referring to this bit: http://docs.zope.org/zope2/releases/2.12/INSTALL.html#buildout-instances where I didn't notice the word starting in Create a Zope configuration file starting as follows. Thanks for the very quick reply! Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ 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 )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
On 12/29/09 15:28 , Martijn Faassen wrote: Hanno Schlichting wrote: On Mon, Dec 28, 2009 at 10:57 PM, Martijn Faassen faas...@startifact.com wrote: Hanno Schlichting wrote: The ZTK no longer contains any zope.app packages. I think we should be careful to just remove the zope.app packages from the ZTK entirely. I.e. we should maintain the versions of the zope.app.* packages that were in Zope 3.4 (or at least the original Zope 3 tree) in the ZTK for the time being. Otherwise we make people's life rather difficult. I disagree. In my opinion it's not part of the job of the ZTK to provide backwards compatibility with Zope 3. The toolkit is not a replacement for all of Zope 3 and you cannot run a Zope 3 application even after following all the refactorings on the toolkit alone. If users of Zope 3 want an upgrade story, they need to get together and make a new Zope 3 release which is based on the ZTK. Totally ignoring our community's responsibility towards backwards compatibility and delegating it to a mythical set of Zope 3 maintainers isn't an option at all. We need to provide an upgrade path from pre-ZTK applications to ZTK applications. I don't know what you mean with pre-ZTK applications. Are those Zope 2 applications? Zope 3? Grok? All of those can keep working as long as Zope 2, Zope 3 and Grok make sure they keep working. Zope 2 has already done so. I saw that there is an effort for Grok as well. Zope 3 does not seem to have any maintainer at the moment, but I do not think it is fair to shift that responsibility to others by forcing zope.app.* into the ZTK. Wichert. ___ 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 )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
Wichert Akkerman wrote: I don't know what you mean with pre-ZTK applications. Are those Zope 2 applications? Zope 3? Grok? Yes, yes, yes. You know, us, who get together here on zope-dev to work together. All of those can keep working as long as Zope 2, Zope 3 and Grok make sure they keep working. That's us, here on zope-dev working together. Zope 3 does not seem to have any maintainer at the moment We're here on zope-dev to help maintain it. but I do not think it is fair to shift that responsibility to others by forcing zope.app.* into the ZTK. That's not what happened. What just happened that the responsibility was *forced out* of the ZTK. I'm all for taking away responsibility from the ZTK, but not just like that. Regards, Martijn ___ 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 )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
On 12/29/09 16:23 , Martijn Faassen wrote: Wichert Akkerman wrote: but I do not think it is fair to shift that responsibility to others by forcing zope.app.* into the ZTK. That's not what happened. What just happened that the responsibility was *forced out* of the ZTK. I'm all for taking away responsibility from the ZTK, but not just like that. I read this as 'the ZTK and Zope 3 are the same thing'. Is that what you are trying to say? Wichert. ___ 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 )
[Zope-dev] removing zope.app from the ZTK
Hi there, Fastest summary: * removing responsibility from the ZTK, yes, but not like this. Quick summary: * I agree we should dump most, perhaps all, of the code that is in zope.app.* from the ZTK. Most of these packages will likely eventually become unmaintained. * We as a community have a responsibility to help the users of our software to help get to a world with a vastly smaller set of zope packages. We can't just ignore that responsibility. * we can make a plan about when we will declare a lot of packages without support, after we've had some more experience with upgrading code. Longer: Here's my position on the role of zope.app within the ZTK and in our community. We as the Zope community have been maintaining Zope 3 for years now. We have a lot of software that depends on it. Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. As part of the dependency refactoring project, we've been factoring code out of zope.app.* packages that we do use and leaving the old zope.app.* packages behind. A philosophical point: just because we have a dependency structure that *allows* us to remove zope.app.* from the dependency tree of the ZTK doesn't mean that only zope.* contains useful code that can be shared between our community. It's been a convenient shortcut to think in this way, but it isn't necessarily the case that we're done moving code out of zope.app.* into zope.*. I'll ignore this point below and assume that zope.app.* only contains old stuff that we don't want to maintain in the future. Recently the zope.app.* packages were entirely removed from the ZTK. That we wish to remove zope.app.* from the ZTK at some point follows from the previous discussion, but as a community, I think we've certainly done this step too fast. Since this is a *big* change and was done without sufficient discussion, I've reverted this change and added these packages back into the ZTK, in the under review section where they were before, and back to the versions list. We need to maintain zope.app.* for the time being to help people off zope.app. We can't just drop the ball on this and offer no support. The argument was made that the Zope 2 project has already taken care of this, and that other projects that use Zope 3 should also maintain their own backwards compatibility list separately and just work out their own upgrade stories. This is exactly one of those jobs we should do centrally, and not delegate to subcommunities. That's neglecting our responsibility as a community and ignoring a *value* of our community. In what form we should maintain the zope.app.* packages? I can see a construction where the main ZTK consists only of non-zope.app packages and that we, as ZTK developers, maintain a separate project for zope.app.*. This way we can continue to maintain and test this project as a community, and help people with a smooth upgrade. We cannot just stop testing whether this works, or stop maintaining versions that work together. And that's what we did. We can make a plan as to when we *will* officially drop support for these packages, or hand over maintainership to others, etc, and how we will help our community to get there. Our plan doesn't need to be perfect; we can expect some difficulty in this upgrade, but we should at least make a reasonable attempt. Regards, Martijn ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On 12/29/09 16:25 , Martijn Faassen wrote: Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. I feel a disconnect here. As I see it the ZTK is not a 'leaner, meaner Zope 3'. Zope 3 is a modular application framework, while the ZTK is a small framework that can be used to build applications or applications frameworks. ZTK has no history since it never existed before (and still is only vapourware since it has no releases nor a release manager), so it does not have any backwards compatibility to worry about. It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. Wichert. ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On 12/29/09 16:39 , Wichert Akkerman wrote: On 12/29/09 16:25 , Martijn Faassen wrote: Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. I feel a disconnect here. As I see it the ZTK is not a 'leaner, meaner Zope 3'. Zope 3 is a modular application framework, while the ZTK is a small framework that can be used to build applications or applications frameworks. That should have said 'Zope 3 is a modular application'. Wichert. ___ 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 )
Re: [Zope-dev] Zope 2.12.2 SyntaxError on installation
Marius Gedminas wrote: Well. You didn't specify a database file in your zope,conf it seems. Without a declaration, there's no database. Makes sense, in a rather user-unfriendly way. May I suggest the documentation be amended to supply a closer-to-working zope.conf? I'm referring to this bit: http://docs.zope.org/zope2/releases/2.12/INSTALL.html#buildout-instances where I didn't notice the word starting in Create a Zope configuration file starting as follows. Hmm, well, a full zope.conf is a bit bloated to go in those docs, which is why I worded it the way I did... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Wichert Akkerman wrote: On 12/29/09 16:25 , Martijn Faassen wrote: Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. I feel a disconnect here. As I see it the ZTK is not a 'leaner, meaner Zope 3'. Zope 3 is a modular application framework, while the ZTK is a small framework that can be used to build applications or applications frameworks. ZTK has no history since it never existed before (and still is only vapourware since it has no releases nor a release manager), so it does not have any backwards compatibility to worry about. The sense of irony of you feeling a disconnect is rather strong here. I was the one who proposed the ZTK in the first place, remember? It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. I'm glad the message of what the ZTK is that I tried to spread so hard has arrived so well. The ZTK wants to reduce responsibilities. One of the responsibilities you gain when you want to reduce responsibilities is to do this responsibly. Regards, Martijn ___ 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 )
[Zope-dev] zope.testing 3.8.6 emits deprecation warnings from itself?
Hi, I hate DeprecationWarnings at the best of times, since no one actually does anything about them until whatever they're bleating about is actually gone anyway, but zope.testing has outdone itself. Whoever introduced that warning, if you're going to do so, please solve any problems with code in the actual package itself before releasing. zope.testing.testrunner.debug imports doctest from zope.testing and so bleats whenever tests are run with zope.testing 3.8.6. Why was 3.8.6 released when it still emits these warnings itself? Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Tue, Dec 29, 2009 at 10:39 AM, Wichert Akkerman wich...@wiggy.net wrote: It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. Agreed; the lean mean ZTK is more interesting than this ZTK + zope.app construct. Creating a second known-good-set construct based on the ZTK and adding the selected zope.app package sounds like a straightforward task. It should be able to reuse the testing policies with little or no change. I agree with Martijn's desire for caution, however. This split should be done, but this is a split, not a simple removal of the zope.app packages without setting up this ZTK+ construct. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On 12/29/09 17:00 , Martijn Faassen wrote: Wichert Akkerman wrote: On 12/29/09 16:25 , Martijn Faassen wrote: Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. I feel a disconnect here. As I see it the ZTK is not a 'leaner, meaner Zope 3'. Zope 3 is a modular application framework, while the ZTK is a small framework that can be used to build applications or applications frameworks. ZTK has no history since it never existed before (and still is only vapourware since it has no releases nor a release manager), so it does not have any backwards compatibility to worry about. The sense of irony of you feeling a disconnect is rather strong here. I was the one who proposed the ZTK in the first place, remember? It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. I'm glad the message of what the ZTK is that I tried to spread so hard has arrived so well. The ZTK wants to reduce responsibilities. One of the responsibilities you gain when you want to reduce responsibilities is to do this responsibly. You are ignoring my point though: why should the ZTK have to be burdened with trying to be backwards compatible with something that it never was? Why are you insisting on putting Zope3 in it? Wichert. ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
I don't think the ZTK as defined by the historical constraints under discussion here has much attraction for a large number of folks who are otherwise willing to put effort into maintaining Zope packages. For these folks, any reduction in number of dependencies and test maintenance is a net win, because they just don't use the stuff they throw out, and they don't have any Grok or legacy Zope3 apps in production to maintain that uses this stuff either. So maybe these folks should come up with their own KGS for whatever they need as a subset of the ZTK. In particular, maybe Zope2 should just be based on this subset. Martijn Faassen wrote: Wichert Akkerman wrote: On 12/29/09 16:25 , Martijn Faassen wrote: Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. I feel a disconnect here. As I see it the ZTK is not a 'leaner, meaner Zope 3'. Zope 3 is a modular application framework, while the ZTK is a small framework that can be used to build applications or applications frameworks. ZTK has no history since it never existed before (and still is only vapourware since it has no releases nor a release manager), so it does not have any backwards compatibility to worry about. The sense of irony of you feeling a disconnect is rather strong here. I was the one who proposed the ZTK in the first place, remember? It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. I'm glad the message of what the ZTK is that I tried to spread so hard has arrived so well. The ZTK wants to reduce responsibilities. One of the responsibilities you gain when you want to reduce responsibilities is to do this responsibly. Regards, Martijn ___ 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 ) ___ 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 )
[Zope-dev] Documentation on the Zope 2 release process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I started documenting the Zope 2 release process (Zope 2.12 only for now): svn+ssh://svn.zope.org/repos/main/zope2docs/trunk/maintenance/index.rst Hints and feedback appreciated. Andreas - -- ZOPYX Ltd. Co KG \ zopyx group Charlottenstr. 37/1 \ The full-service network for your D-72070 Tübingen \ Python, Zope and Plone projects www.zopyx.com, i...@zopyx.com \ www.zopyxgroup.com - E-Publishing, Python, Zope Plone development, Consulting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAks6PwAACgkQCJIWIbr9KYyqTgCeLfknpgqeGLKpPM9Lj6aU57of kDgAoMUXidpW3eOfpIY8AQI7O5lFK8cM =Tr+l -END PGP SIGNATURE- attachment: lists.vcf___ 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 )
Re: [Zope-dev] Documentation on the Zope 2 release process
On Tue, Dec 29, 2009 at 6:40 PM, Andreas Jung li...@zopyx.com wrote: I started documenting the Zope 2 release process (Zope 2.12 only for now): svn+ssh://svn.zope.org/repos/main/zope2docs/trunk/maintenance/index.rst Hints and feedback appreciated. Cool. Looks quite good already. You could include prod Hanno to make Windows binary eggs. Most of the time I'll see and do that by myself though. Hanno ___ 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 )
Re: [Zope-dev] windows newslines in doctests
Fred Drake wrote: It's interesting to note that Python 2.6's doctest doesn't use universal newlines, but zope.testing.doctest. Good think we haven't just deprecated zope.testing.doctest and defecated on zope.testing in the process... ...oh wait. Interestingly, the doctests I referred to in my original post were Manuel doctests, which (Benji, lemme know if I'm wrong...) use Python's doctest module rather than zope.testing's one, in which case I think you may have hit the nail precisely on the head... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] Zope 2.12.2 SyntaxError on installation
On Tue, Dec 29, 2009 at 03:59:07PM +, Chris Withers wrote: Marius Gedminas wrote: Well. You didn't specify a database file in your zope,conf it seems. Without a declaration, there's no database. Makes sense, in a rather user-unfriendly way. May I suggest the documentation be amended to supply a closer-to-working zope.conf? I'm referring to this bit: http://docs.zope.org/zope2/releases/2.12/INSTALL.html#buildout-instances where I didn't notice the word starting in Create a Zope configuration file starting as follows. Hmm, well, a full zope.conf is a bit bloated to go in those docs, which is why I worded it the way I did... Is 46 lines too much? That's how much it takes to have python instancehome default-publisher-encoding # hm, what's this? first time I see one eventlog logger access http-server zodb_db main zodb_db temporary with a couple of %defines and comments. Or we could put a sample zope.conf somewhere on the web (heck, in svn is fine, using those nice *checkout* urls we've already used for downloading buildout's bootstrap.py or the Zope 2.12.2 versions.cfg). It'd be even better if there was a command I could run to generate an up-to-date default zope.conf, like mkzopeinstance does. Is there one? Maybe there's a place for bin/zopectl init that would mkdir etc var log and write a default etc/zope.conf? (Thanks to whoever came up with bin/zopectl adduser, BTW, much appreciated!) Now the using buildout section of INSTALL.rst leaves the user to write one completely from scratch without any tool support or even a link to documentation, and I'd like to fix this in case I have to set up a Zope 2.x instance ever again ;-) Cheers! Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ 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 )
Re: [Zope-dev] zope.testing 3.8.6 emits deprecation warnings from itself?
On Tue, Dec 29, 2009 at 04:04:34PM +, Chris Withers wrote: I hate DeprecationWarnings at the best of times, since no one actually does anything about them until whatever they're bleating about is actually gone anyway, but zope.testing has outdone itself. Some background, because you're obviously not following all the threads currently active on zope-dev (nobody can!): * there was a zope.testing 3.8.4 release that dropped some unused imports from zope.testing.doctestunit * that turned out to break many things, including zope.container and (according to some reports) zope.interface * there were changes made to zope.testing trunk, backpedaling a bit and adding those legacy imports back, with a deprecation warning for the whole zope.testing.doctestunit, and (for good measure) a deprecation warning for zope.testing.doctest. * I released zope.testing 3.8.5 with the deprecation warning (which turned out to be triggered by zope.testing itself, making the warning quite useless) because I thought having a spurious warning is better than having broken zope.interface * I then had to release zope.testing 3.8.6 because the 3.8.5 egg was broken (thank you setuptools for the sudden but inevitable stab in the back) * Fabio Tranchitella is working to make the zope.testing.doctest deprecation warning useful by doing scary things like converting zope.testing.doctest from a module into a package that has all the code in __init__.py. He asked for a review of his changes. I'm too scared to do that. * Meanwhile there are discussions about issues switching from old zope.testing.doctest to stdlib's doctest with Windows and newlines. * I'd rather revert back the state of things as of zope.testing 3.8.4 with the legacy zope.testing.doctestunit imports added back and a single deprecation warning for zope.testing.doctestunit, until we figure out the difficult part: what to do with zope.testing.doctest itself. Opinions? Whoever introduced that warning, if you're going to do so, please solve any problems with code in the actual package itself before releasing. zope.testing.testrunner.debug imports doctest from zope.testing and so bleats whenever tests are run with zope.testing 3.8.6. Why was 3.8.6 released when it still emits these warnings itself? Because 3.8.5 broke running code. Why was 3.8.5 released when it broke running code? Because there were no comments explaining that those unused imports were part of the API, and no buildbots to give a timely warning about unexpected breakage of other packages. Welcome to the wonderful world of non-monolithic Zope 3. Fasten your seat-belt, it could get bumpy. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Wichert Akkerman wrote: [snip] You are ignoring my point though: why should the ZTK have to be burdened with trying to be backwards compatible with something that it never was? Why are you insisting on putting Zope3 in it? We should not remove it until we have a good way to upgrade people away from it. And let's please not turn this around: I'm not putting anything *in*. Something was *removed*. Let's remove it responsibly. Not just disclaim responsibility and drop it all. Regards, Martijn ___ 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 )
Re: [Zope-dev] Zope 2.12.2 SyntaxError on installation
On Tue, Dec 29, 2009 at 9:43 PM, Marius Gedminas mar...@gedmin.as wrote: On Tue, Dec 29, 2009 at 03:59:07PM +, Chris Withers wrote: Marius Gedminas wrote: It'd be even better if there was a command I could run to generate an up-to-date default zope.conf, like mkzopeinstance does. Is there one? Maybe there's a place for bin/zopectl init that would mkdir etc var log and write a default etc/zope.conf? (Thanks to whoever came up with bin/zopectl adduser, BTW, much appreciated!) Well, either you use mkzopeinstance, which indeed generates an instance for you with all things included, or if you use buildout you use a recipe like plone.recipe.zope2instance, in which case all it takes is: [instance] recipe = plone.recipe.zope2instance eggs = Zope2 user = admin:password http-address = 127.0.0.1:8080 and there's lots of documentation of the available options on the recipe page on PyPi. The current buildout docs are aimed at people who know how to set up Zope2 and don't want any help. Those are comfortable reading ZConfig definition files. Hanno ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Chris McDonough wrote: I don't think the ZTK as defined by the historical constraints under discussion here has much attraction for a large number of folks who are otherwise willing to put effort into maintaining Zope packages. For these folks, any reduction in number of dependencies and test maintenance is a net win, because they just don't use the stuff they throw out, and they don't have any Grok or legacy Zope3 apps in production to maintain that uses this stuff either. So maybe these folks should come up with their own KGS for whatever they need as a subset of the ZTK. In particular, maybe Zope2 should just be based on this subset. I think the ZTK should be a smaller thing, but we need to find what that smaller thing is first. I agree with the general idea underlying this move, just not the way it was done, disclaiming responsibility. I'm quite sure that most of the zope.app.* packages that were dropped are just not very useful anymore. But we should drop them responsibly. Regards, Martijn ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Tue, Dec 29, 2009 at 9:54 PM, Martijn Faassen faas...@startifact.com wrote: And let's please not turn this around: I'm not putting anything *in*. Something was *removed*. Let's remove it responsibly. Not just disclaim responsibility and drop it all. So far I defined the ZTK based on what we wrote on http://docs.zope.org/zopetoolkit/about/coreextra.html. I never considered those zope.app packages to be part of the ZTK. For me that was only a technical implementation detail on how to actually get to something that fullfils those criteria about core packages. But it seems our understanding is different and you want the responsibility of moving Zope 3 users over to the ZTK to be the responsibility of the ZTK. I don't agree with that, but that's my problem :) To be able to make more actual progress I moved Zope2 off the toolkit for now and we'll continue on our own. If at some point the ZTK offers a package set, that is actually anywhere close to what Zope2 uses, we can consider using it again. From my Zope2/Plone perspective I'm just not interested at all in any zope.app code anymore. Hanno ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Fred Drake wrote: On Tue, Dec 29, 2009 at 10:39 AM, Wichert Akkerman wich...@wiggy.net wrote: It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. Agreed; the lean mean ZTK is more interesting than this ZTK + zope.app construct. Heh. I agree too. :) Creating a second known-good-set construct based on the ZTK and adding the selected zope.app package sounds like a straightforward task. It should be able to reuse the testing policies with little or no change. Agreed. We should find some form of status for the 'zope.app.*' packages that makes sense. These packages are already largely deprecated. Many of them are slated for deep freeze maintenance. We can talk about removing such packages from it, or even putting the whole thing into deep freeze maintenance. But right now we need to provide some guidance for how people can move away from these packages in a sane manner. And we should make sure we continue to test the zope.app.* packages when we make ZTK changes, for the time being. Let's work out a plan and a timeline. I agree with Martijn's desire for caution, however. This split should be done, but this is a split, not a simple removal of the zope.app packages without setting up this ZTK+ construct. Yes. Regards, Martijn ___ 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 )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
Wichert Akkerman wrote: On 12/29/09 16:23 , Martijn Faassen wrote: Wichert Akkerman wrote: but I do not think it is fair to shift that responsibility to others by forcing zope.app.* into the ZTK. That's not what happened. What just happened that the responsibility was *forced out* of the ZTK. I'm all for taking away responsibility from the ZTK, but not just like that. I read this as 'the ZTK and Zope 3 are the same thing'. Is that what you are trying to say? No. I've argued strenuously against that notion in the past, in fact. I agree with the general idea of making the ZTK something much like the currently proposed set. I just don't like the execution. Like it or not, we can't just drop obligations to backwards compatibility just like that, and we should manage these responsibilities in common as much as we can. And then if we can responsibly lose these responsibilities, by all means. Regards, Martijn ___ 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 )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hanno Schlichting wrote: On Mon, Dec 28, 2009 at 10:57 PM, Martijn Faassen faas...@startifact.com wrote: Hanno Schlichting wrote: The ZTK no longer contains any zope.app packages. I think we should be careful to just remove the zope.app packages from the ZTK entirely. I.e. we should maintain the versions of the zope.app.* packages that were in Zope 3.4 (or at least the original Zope 3 tree) in the ZTK for the time being. Otherwise we make people's life rather difficult. I disagree. In my opinion it's not part of the job of the ZTK to provide backwards compatibility with Zope 3. The toolkit is not a replacement for all of Zope 3 and you cannot run a Zope 3 application even after following all the refactorings on the toolkit alone. If users of Zope 3 want an upgrade story, they need to get together and make a new Zope 3 release which is based on the ZTK. Totally ignoring our community's responsibility towards backwards compatibility and delegating it to a mythical set of Zope 3 maintainers isn't an option at all. The reality is that the zope.app.* packages don't fit the mission of the ZTK: they aren't widely-reusable libraries, but pieces of a particular appserver / framework. The other reality is that nobody is stepping up to do the work to maintain that appserver. There is *not* BBB issue with dropping those packagse from the ZTK, because everybody who is currently deployed with them has a valid way to use them *without* the ZTK. Pushing the burden of maintenance of those packages onto the ZTK, instaead of onto the portions of the community who use them, reduces the viability of the ZTK for almost no gain. We need to provide an upgrade path from pre-ZTK applications to ZTK applications. This upgrade path can take the form of a set of versions of zope.app.* libraries that people can choose to install for backwards compatibility. We should maintain this set of versions as part of the ZTK's test regime at the very least, otherwise we'll inevitably break something. Toolkits aren't frameworks or appservers: migration paths aren't part of their story: if you need a tool which doesn't come with the toolkit, you purchase it seaparately. If the tool *used* to come with the toolkit, and you still need it, you pull it out of the old toolkit and keep it on the side when you replace the toolkit. Defining those upgrade paths is the responsibility of the various groups consuming the (new) ZTK: in the case of Zope2, the Zope2 maintainers have chosen to do the work to remove all dependencies on zope.app.* packages from Zope2, leaving Zope2 free to use a zope-app-free ZTK without any issues. For Zope2 we have covered the upgrade story already. Zope 2.12 uses its own KGS, which includes the entire set of zope.app packages in compatible versions. Let's please please please maintain that set of zope.app.* packages centrally. Zope 2 isn't the only consumer of these packages. What set? Why do you think that any given set of them is worth maintaining? Grok uses some subset of them, while a Zope3 app uses a bigger set, but Zope2 uses none: why is Grok's set (or Zope3's) important enough for the wider group of ZTK developers to care about? On a more practical note, it's actually just not helpful to include version pins for any zope.app packages in the ztk.cfg. I can add any arbitrary set of version definitions there. Then run the test-ztk tests and all tests will always pass. Since the packages under tests don't include nor depend on any zope.app packages, their test result is independent of any zope.app version pins. Then we certainly need to do more than version pins. We also need to test these packages. -1 to this change. I'm going to add the zope.app.* packages back to the ZTK until we've had a proper discussion about how, as a Zope community, we go forward with this. Delegating this responsibility *separately* to sub projects is just plain silly. You are treading on very dangerous ground here: commit wars are not a good way to solve this problem. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks6cZcACgkQ+gerLs4ltQ79/gCgxBltITz0Rn9DEZxvwK2EleLQ np0An3vNmFWWGE2/OzSOLL+zTWA/mvrt =LFUf -END PGP SIGNATURE- ___ 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 )
[Zope-dev] moving the zope.app.* packages out of the ZTK: towards a plan
Hi there, Let me sketch out some ideas for a plan: * we create a new project, zopeapp, with the same structure as the zopetoolkit (sans documentation) * we pull the zope.app.* packages from the ZTK and move them into zopeapp. * we make sure we have a way to regularly run the zopeapp tests in conjunction with the ZTK. * we then move towards a release of ZTK 1.0 (see Hanno's mail for lots of things we need to work out) * we also release zopeapp 1.0 in conjunction with it. This is just a backwards compatibility KGSish thing. We explicitly don't strive to document it, etc. * we announce that we strive to deprecate what's in zopeapp 1.0 and that we expect users to shift to use ZTK packages as much as possible and report back any difficulties they have with this. * this will help us determine whether there is still useful code left in zopeapp that we wish to salvage into the ZTK or otherwise maintain. * this will also help us determine which packages in zopeapp are more generally useful, and strive to isolate them from the rest of zopeapp. zope.formlib is an example of this. * depending on our experiences in Zope 2, Zope 3 and Grok apps we can decide whether we can put zopeapp in the deep freeze: not maintain it anymore. * we then also look into shunting away the zope.app.* packages from the top-level SVN into an this is old stuff area by that time. Note that we also have a long-standing idea of a wider KGS which contains the ZTK plus perhaps zopeapp plus more, such as z3c.form. This is a related exercise. Once we have some discussion we can hopefully flesh out this plan, put in some dates and such, and put the plan in the Zope Toolkit documentatino. Regards, Martijn ___ 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 )
Re: [Zope-dev] Top-level namespace package for Zope 2 ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: On Tue, Dec 29, 2009 at 6:40 PM, Baiju M mba...@zeomega.com wrote: Hi, I was going through Zope 2 source code today. There are 20+ top-level packages specific to Zope 2. Would it be useful if we move those packages to a top-level namespace package. I mean something similar to: zope.app.*, grokcore.*, repoze.bfg.* ? One more example: plone.app. No, it would not be useful. The BBB damage would be catastrophic. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks6cd8ACgkQ+gerLs4ltQ5iyACgt/OdKbAjkNBvE1j6tsbm6l/h jIwAoMvLXFChEowqReyklV6XwOO9pJDi =m8B7 -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: On 12/29/09 16:25 , Martijn Faassen wrote: Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. I feel a disconnect here. As I see it the ZTK is not a 'leaner, meaner Zope 3'. Zope 3 is a modular application framework, while the ZTK is a small framework that can be used to build applications or applications frameworks. ZTK has no history since it never existed before (and still is only vapourware since it has no releases nor a release manager), so it does not have any backwards compatibility to worry about. It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. +1. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks6cmsACgkQ+gerLs4ltQ403QCgsxsE6Ug9ucN3b+S2EQCQS0GB XesAoI12dh6pdKXuSc1zhLj7HVRxJwOe =mDQ+ -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Wichert Akkerman wrote: [snip] You are ignoring my point though: why should the ZTK have to be burdened with trying to be backwards compatible with something that it never was? Why are you insisting on putting Zope3 in it? We should not remove it until we have a good way to upgrade people away from it. Who is upgrading? There are not historical users of the ZTK, only users of package sets with greater or lesser intersections with the ZTK. And let's please not turn this around: I'm not putting anything *in*. Something was *removed*. Let's remove it responsibly. Not just disclaim responsibility and drop it all. You are acting like we have code in the wild which needs to upgrade from some released version of the ZTK to a newer one, and which will thereby break. There is *no* released version: we can't possibly break anybody. People who want to consume the yet-to-be-released ZTK are going to need to make choices about how they include various pacakges which aren't part of it; there is nothing surprising about that at all. You seem to be worried that the removed packages will bitrot because they aren't part of the ZTK: going forward, that may in fact be so, but *only if they aren't being used by people who also track the ZTK*, in which case their removal has harmed no one. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks6c4gACgkQ+gerLs4ltQ4z6wCffuFNJ0a6aonyHbQUCvntT9hX sWkAnjcTC4enCKp8xkMX/xfZlZtKvK7F =fNFn -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Chris McDonough wrote: I don't think the ZTK as defined by the historical constraints under discussion here has much attraction for a large number of folks who are otherwise willing to put effort into maintaining Zope packages. For these folks, any reduction in number of dependencies and test maintenance is a net win, because they just don't use the stuff they throw out, and they don't have any Grok or legacy Zope3 apps in production to maintain that uses this stuff either. So maybe these folks should come up with their own KGS for whatever they need as a subset of the ZTK. In particular, maybe Zope2 should just be based on this subset. I think the ZTK should be a smaller thing, but we need to find what that smaller thing is first. I agree with the general idea underlying this move, just not the way it was done, disclaiming responsibility. I'm quite sure that most of the zope.app.* packages that were dropped are just not very useful anymore. But we should drop them responsibly. The maintainer who dropped them also went to a great deal of trouble to ensure that the dependencies were fixed, and that what remains is a coherent and usable set of the packages which used to be Zope3. Because of his work, and that of others, the Zope2 trunk can now run against the zope.app-free ZTK he created. You need to identify whose ox is being gored here by dropping those packages: I don't see anybody but you arguing for their inclusion. In particular, I don't see anybody who knows *which* zope.app packages they need, and has a credible argument for why those pacakges should be maintained within the ZTK, rather than by the folks who actually use them. If the ZTK is to be held hostage to a (nonsensical) BBB for nameless users, I would be in favor of just copying Hanno's version of the ZTK config into the Zope2 tree and have Zope2 ignore the ZTK per-se. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks6dTgACgkQ+gerLs4ltQ4KIQCcDjWOMCw1clCGbv03CxEflkRv e5sAn3HLimvx7WbWEo7hujnzItV1q5XI =z8P+ -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Tue, Dec 29, 2009 at 4:04 PM, Martijn Faassen faas...@startifact.com wrote: But right now we need to provide some guidance for how people can move away from these packages in a sane manner. And we should make sure we continue to test the zope.app.* packages when we make ZTK changes, for the time being. Let's work out a plan and a timeline. I think we disagree as to the scale of what's needed still. I'd be happy to see a copy of the ZTK tree get made to some recognizable name (ZATK, for Zope App Toolkit, would suffice), let Hanno commit his removal of the zope.app packages from the ZTK, and then make the ZATK refer to that version of the ZTK instead of including it directly. The only timeline that's needed is the order of the commits. If there's anyone who wants to maintain the new bastard-stepchild, they're free to step forward. There's no obligation on the part of the ZTK maintainers to do that, nor should there be. That's the whole point. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Hanno Schlichting wrote: On Tue, Dec 29, 2009 at 9:54 PM, Martijn Faassen faas...@startifact.com wrote: And let's please not turn this around: I'm not putting anything *in*. Something was *removed*. Let's remove it responsibly. Not just disclaim responsibility and drop it all. So far I defined the ZTK based on what we wrote on http://docs.zope.org/zopetoolkit/about/coreextra.html. I never considered those zope.app packages to be part of the ZTK. For me that was only a technical implementation detail on how to actually get to something that fullfils those criteria about core packages. That document should've helped clue you in about this too: The Zope Toolkit Steering Group is the final arbiter of which libraries are in Zope Toolkit or not. The idea was not to have unilateral decisions about this but to have some discussion first. I think dropping lots of libraries counts as something we need to talk about before it happens. Again, I'm fine with the *goal* of making the ZTK those packages, but we can't just leave the rest behind. But it seems our understanding is different and you want the responsibility of moving Zope 3 users over to the ZTK to be the responsibility of the ZTK. I don't agree with that, but that's my problem :) The ZTK cannot be an excuse to just drop support for a large part of the existing users of the ZTK. It's a *means* to do so. To be able to make more actual progress I moved Zope2 off the toolkit for now and we'll continue on our own. If at some point the ZTK offers a package set, that is actually anywhere close to what Zope2 uses, we can consider using it again. From my Zope2/Plone perspective I'm just not interested at all in any zope.app code anymore. The irony is that almost nobody is, including myself. But the situation is also that you as Zope 2 developers have a plan to support users that do still depend on zope.app code. Why don't you throw that plan into the wider group of people here? We have a shared problem of backwards compatibility, right? Perhaps less for Zope 2 than for other Zope Toolkit using systems, as you never used the UI or the content types. Regards, Martijn ___ 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 )
Re: [Zope-dev] Zope 2.12.2 SyntaxError on installation
On Tue, Dec 29, 2009 at 09:56:01PM +0100, Hanno Schlichting wrote: On Tue, Dec 29, 2009 at 9:43 PM, Marius Gedminas mar...@gedmin.as wrote: On Tue, Dec 29, 2009 at 03:59:07PM +, Chris Withers wrote: Marius Gedminas wrote: It'd be even better if there was a command I could run to generate an up-to-date default zope.conf, like mkzopeinstance does. Is there one? Maybe there's a place for bin/zopectl init that would mkdir etc var log and write a default etc/zope.conf? (Thanks to whoever came up with bin/zopectl adduser, BTW, much appreciated!) Well, either you use mkzopeinstance, which indeed generates an instance for you with all things included, *nod* or if you use buildout you use a recipe like plone.recipe.zope2instance, in which case all it takes is: [instance] recipe = plone.recipe.zope2instance eggs = Zope2 user = admin:password http-address = 127.0.0.1:8080 and there's lots of documentation of the available options on the recipe page on PyPi. Ah, but then why The Official Zope 2.12 Installation Guide at http://docs.zope.org/zope2/releases/2.12/INSTALL.html#buildout-instances doesn't even mention plone.recipe.zope2instance? Should it? The namespace of the recipe alone is scary -- I don't want Plone, I just want Zope, cry bewildered newbie users! The current buildout docs are aimed at people who know how to set up Zope2 and don't want any help. Those are comfortable reading ZConfig definition files. Do you think that's how it should be, or would you like to improve the situation for Zope 2.13 (or even 2.12.3)? Do you think a command such as my suggested 'zopectl init' would be convenient for both new and advanced users? I'm willing to put some work to improve the docs or tools, but I need feedback! Cheers! Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ 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 )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
Tres Seaver wrote: [snip] The reality is that the zope.app.* packages don't fit the mission of the ZTK: they aren't widely-reusable libraries, but pieces of a particular appserver / framework. The other reality is that nobody is stepping up to do the work to maintain that appserver. I agree. But I'm not talking about maintaining the app server. I'm talking about helping people to move away from most of those packages, or otherwise find ways to maintain them. There is *not* BBB issue with dropping those packagse from the ZTK, because everybody who is currently deployed with them has a valid way to use them *without* the ZTK. Pushing the burden of maintenance of those packages onto the ZTK, instaead of onto the portions of the community who use them, reduces the viability of the ZTK for almost no gain. I think the ZTK developers have a responsibility to this use of the ZTK just like to anyone else's use. Just stopping to test whether all of this works with the ZTK isn't fulfilling our responsibility. [snip] Defining those upgrade paths is the responsibility of the various groups consuming the (new) ZTK: in the case of Zope2, the Zope2 maintainers have chosen to do the work to remove all dependencies on zope.app.* packages from Zope2, leaving Zope2 free to use a zope-app-free ZTK without any issues. Maintaining a coherent set of versions of zope.app.* packages is a responsibility that we can share in our community. Dropping this responsibility into a black hole by suddenly stopping to do so within the context of the ZTK is not the right way forward. For Zope2 we have covered the upgrade story already. Zope 2.12 uses its own KGS, which includes the entire set of zope.app packages in compatible versions. Let's please please please maintain that set of zope.app.* packages centrally. Zope 2 isn't the only consumer of these packages. What set? Why do you think that any given set of them is worth maintaining? Grok uses some subset of them, while a Zope3 app uses a bigger set, but Zope2 uses none: why is Grok's set (or Zope3's) important enough for the wider group of ZTK developers to care about? Because we have a ton of installed base out there and we have a responsibility to maintain backwards compatibility. If some people don't care about that it's fine, but I expect at least some measure of cooperation with those who do. -1 to this change. I'm going to add the zope.app.* packages back to the ZTK until we've had a proper discussion about how, as a Zope community, we go forward with this. Delegating this responsibility *separately* to sub projects is just plain silly. You are treading on very dangerous ground here: commit wars are not a good way to solve this problem. Sure. Unilaterally removing a huge amount of packages from a shared KGS is also not a good way to solve this problem. Regards, Martijn ___ 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 )
Re: [Zope-dev] zope.testing 3.8.6 emits deprecation warnings from itself?
* 2009-12-29 21:54, Marius Gedminas wrote:
* Fabio Tranchitella is working to make the zope.testing.doctest
deprecation warning useful by doing scary things like converting
zope.testing.doctest from a module into a package that has all the
code in __init__.py. He asked for a review of his changes. I'm too
scared to do that.
* Meanwhile there are discussions about issues switching from old
zope.testing.doctest to stdlib's doctest with Windows and newlines.
Note that the current trunk of zope.testing is already using the standard
doctest; zope.testing.doctest is still there for backward compatibility,
and emits a single deprecation warning at import time. We were considering
about switching to a deprecation warning issued at each usage of
zope.testing.doctest.{DocFileSuite,DocTestSuite}, though.
I tested the whole ZTK (hey, with the zope.app.* packages too :)) and
there were no regressions.
I'd love if somebody would review my changes, though, and help me to make a
release.
Fabio
___
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 )
Re: [Zope-dev] zope.testing 3.8.6 emits deprecation warnings from itself?
On Tue, Dec 29, 2009 at 10:54:03PM +0200, Marius Gedminas wrote: On Tue, Dec 29, 2009 at 04:04:34PM +, Chris Withers wrote: I hate DeprecationWarnings at the best of times, since no one actually does anything about them until whatever they're bleating about is actually gone anyway, but zope.testing has outdone itself. Some background, because you're obviously not following all the threads currently active on zope-dev (nobody can!): * there was a zope.testing 3.8.4 release that dropped some unused imports from zope.testing.doctestunit * that turned out to break many things, including zope.container and (according to some reports) zope.interface * there were changes made to zope.testing trunk, backpedaling a bit and adding those legacy imports back, with a deprecation warning for the whole zope.testing.doctestunit, and (for good measure) a deprecation warning for zope.testing.doctest. * I released zope.testing 3.8.5 with the deprecation warning (which turned out to be triggered by zope.testing itself, making the warning quite useless) because I thought having a spurious warning is better than having broken zope.interface * I then had to release zope.testing 3.8.6 because the 3.8.5 egg was broken (thank you setuptools for the sudden but inevitable stab in the back) * Fabio Tranchitella is working to make the zope.testing.doctest deprecation warning useful by doing scary things like converting zope.testing.doctest from a module into a package that has all the code in __init__.py. He asked for a review of his changes. I'm too scared to do that. * Meanwhile there are discussions about issues switching from old zope.testing.doctest to stdlib's doctest with Windows and newlines. * I'd rather revert back the state of things as of zope.testing 3.8.4 with the legacy zope.testing.doctestunit imports added back and a single deprecation warning for zope.testing.doctestunit, until we figure out the difficult part: what to do with zope.testing.doctest itself. Opinions? Whoever introduced that warning, if you're going to do so, please solve any problems with code in the actual package itself before releasing. zope.testing.testrunner.debug imports doctest from zope.testing and so bleats whenever tests are run with zope.testing 3.8.6. Why was 3.8.6 released when it still emits these warnings itself? Because 3.8.5 broke running code. Why was 3.8.5 released when it broke running code? Both of the previous sentences were meant to say 3.8.4. Thanks again, setuptools. Because there were no comments explaining that those unused imports were part of the API, and no buildbots to give a timely warning about unexpected breakage of other packages. Welcome to the wonderful world of non-monolithic Zope 3. Fasten your seat-belt, it could get bumpy. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Hi there, Tres Seaver wrote: [snip] Who is upgrading? There are not historical users of the ZTK, only users of package sets with greater or lesser intersections with the ZTK. [snip] You are acting like we have code in the wild which needs to upgrade from some released version of the ZTK to a newer one, and which will thereby break. You are acting like the ZTK has no history. The ZTK cannot be an excuse for our community to drop responsibilities. It can and should be a means to do so, but that takes more action than what happened here. Regards, Martijn ___ 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 )
Re: [Zope-dev] Zope 2.12.2 SyntaxError on installation
On Tue, Dec 29, 2009 at 10:53 PM, Marius Gedminas mar...@gedmin.as wrote: Ah, but then why The Official Zope 2.12 Installation Guide at http://docs.zope.org/zope2/releases/2.12/INSTALL.html#buildout-instances doesn't even mention plone.recipe.zope2instance? Should it? The namespace of the recipe alone is scary -- I don't want Plone, I just want Zope, cry bewildered newbie users! Zope 2 has newbie users? I hope for them it has not :) To be honest the reason that recipe isn't mentioned there, is because Chris Withers worked on that section and didn't feel like it belongs there. And nobody else cared a great deal. Note that plone.recipe.zope2instance is actually in the collective, has a bug tracker on Launchpad and is licensed under the ZPL 2.1. The namespace plone just signals written by the Plone community. The current buildout docs are aimed at people who know how to set up Zope2 and don't want any help. Those are comfortable reading ZConfig definition files. Do you think that's how it should be, or would you like to improve the situation for Zope 2.13 (or even 2.12.3)? I actually don't care about that specific piece of documentation. There's hardly ever new users to Zope 2 that'd need it. Do you think a command such as my suggested 'zopectl init' would be convenient for both new and advanced users? zopectl init would be highly confusing. The zopectl script is usually associated with a particular Zope instance. That instance should have been created beforehand. But what would your tool do, that mkzopeinstance isn't doing? Hanno ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Fred Drake wrote: On Tue, Dec 29, 2009 at 4:04 PM, Martijn Faassen faas...@startifact.com wrote: But right now we need to provide some guidance for how people can move away from these packages in a sane manner. And we should make sure we continue to test the zope.app.* packages when we make ZTK changes, for the time being. Let's work out a plan and a timeline. I think we disagree as to the scale of what's needed still. I'm looking at this from the perspective of the discontinuity we will introduce for existing users of the libraries that are now in the Zope Toolkit but were formerly presented as Zope 3, and the guidance we offer for people to move onto the ZTK. When we release ZTK 1.0 we need to have some story for this. For this we need to have some level of commitment (as a community, and I think also a transition obligation of the ZTK maintainers) to maintain zopeapp as a backwards compatibility KGS for a period of time. We need to offer people and projects using the ZTK some guidance as to how to shift to the new way recommend and maintain (the ZTK). In part this can be done on a per-project basis, such as for Zope 2 and Grok. But zopeapp is something we can maintain centrally. I'm also worried about the large amount of Zope 3 code that's out there, which doesn't seem to have anyone watching out for it, possibly as people figured that'd be us, who are dropping that responsibility. [snip] If there's anyone who wants to maintain the new bastard-stepchild, they're free to step forward. There's no obligation on the part of the ZTK maintainers to do that, nor should there be. That's the whole point. On the longer term there shouldn't be any more obligation for the ZTK maintainers than to anyone else. That isn't *no* obligation, just like the Python developers feel they have some obligation not to break Python software even though they do not maintain this software. In the immediate future I think the ZTK maintainers would do well not to forget about the historical background and compatibility constraints of the ZTK. But yes, that's the point of splitting it up, indeed. Regards, Martijn ___ 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 )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
On Tue, Dec 29, 2009 at 22:54, Martijn Faassen faas...@startifact.com wrote: Because we have a ton of installed base out there Do we? I think the debate is somewhat confused here, or possibly it's only me. :) It seems to be two separate issues here: 1. Including these packages in the ZTK. 2. Refactoring with BBB and deprecation. The last thing is obviously important, because these packages are, as you say, out there. But that really isn't very relevant to whether they are included in the ZTK or not. Because the ZTK does *not* have a big installed base. Zope 2.12 doesn't use it. Grok 1.0 doesn't use it. Zope 3.4 doesn't use it. So obviously the refactored zope.app.* packages should have BBB imports and stuff. I think everyone agrees about that. But does that mean these packages must be included in ZTK for the time being? If they do, I don't understand why. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Tue, Dec 29, 2009 at 23:11, Martijn Faassen faas...@startifact.com wrote: I'm looking at this from the perspective of the discontinuity we will introduce for existing users of the libraries that are now in the Zope Toolkit but were formerly presented as Zope 3, and the guidance we offer for people to move onto the ZTK. When we release ZTK 1.0 we need to have some story for this. If Zope 3 people want to move to ZTK, they a Zope 3.5 that is based on the ZTK. It's going to be very hard otherwise... ZTK is, as mentioned, not a successor to Zope 3 in any way. For this we need to have some level of commitment (as a community, and I think also a transition obligation of the ZTK maintainers) to maintain zopeapp as a backwards compatibility KGS for a period of time. What difference would there be between a zopeapp KGS and a Zope3 KGS? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] Zope 2.12.2 SyntaxError on installation
On Tue, Dec 29, 2009 at 11:11:20PM +0100, Hanno Schlichting wrote: On Tue, Dec 29, 2009 at 10:53 PM, Marius Gedminas mar...@gedmin.as wrote: Ah, but then why The Official Zope 2.12 Installation Guide at http://docs.zope.org/zope2/releases/2.12/INSTALL.html#buildout-instances doesn't even mention plone.recipe.zope2instance? Should it? The namespace of the recipe alone is scary -- I don't want Plone, I just want Zope, cry bewildered newbie users! Zope 2 has newbie users? I hope for them it has not :) You got me here ;) I've only had to deal with Zope 2 when I helped random people/nonprofits upgrade/maintain their existing Zope 2 sites. (And by helped I mean had to do that for them). As for myself, I've used Zope 2 in the past (*many* years ago, so things like how do you write a zope.conf from scratch are flushed from my mental caches), before all this newfangled buildout stuff and so on, and I'd like to read docs to learn to use it. To be honest the reason that recipe isn't mentioned there, is because Chris Withers worked on that section and didn't feel like it belongs there. And nobody else cared a great deal. I care. What do y'all Zope-2-maintainer-people think about this patch? Index: doc/INSTALL.rst === --- doc/INSTALL.rst (revision 107265) +++ doc/INSTALL.rst (working copy) @@ -136,11 +136,16 @@ command-line options, run the script wit Creating a buildout-based Zope Instance === -If you wish to use buildout to manage your Zope instance, then the +If you wish to use buildout to manage your Zope instance, there are recipes +like `plone.recipe.zope2instance`__ that automate everything. + + __ http://pypi.python.org/pypi/plone.recipe.zope2instance + +If you're a power user and want to drop to the basics, then the instance is created as follows: * Create a directory for your instance. In this directory, create a - ``etc``, ``logs`` and ``var`` subdirectories. + ``etc``, ``log`` and ``var`` subdirectories. * Download the following file into your instance directory: @@ -186,6 +191,8 @@ used. instancehome $INSTANCE + rest of the stuff that goes into a zope.conf, e.g. databases and log files. + .. highlight:: bash * Now, run the following commands:: Note that plone.recipe.zope2instance is actually in the collective, has a bug tracker on Launchpad and is licensed under the ZPL 2.1. The namespace plone just signals written by the Plone community. To those in the know, but let's not quibble. The current buildout docs are aimed at people who know how to set up Zope2 and don't want any help. Those are comfortable reading ZConfig definition files. Do you think that's how it should be, or would you like to improve the situation for Zope 2.13 (or even 2.12.3)? I actually don't care about that specific piece of documentation. There's hardly ever new users to Zope 2 that'd need it. I'll take that as a +0. Do you think a command such as my suggested 'zopectl init' would be convenient for both new and advanced users? zopectl init would be highly confusing. The zopectl script is usually associated with a particular Zope instance. That instance should have been created beforehand. That's a good point. But what would your tool do, that mkzopeinstance isn't doing? Exist, for one. I don't have a bin/mkzopeinstance when I follow the instructions here: http://docs.zope.org/zope2/releases/2.12/INSTALL.html#buildout-instances Cheers! Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Hey, Tres Seaver wrote: [snip] You need to identify whose ox is being gored here by dropping those packages: I don't see anybody but you arguing for their inclusion. In particular, I don't see anybody who knows *which* zope.app packages they need, and has a credible argument for why those pacakges should be maintained within the ZTK, rather than by the folks who actually use them. That's indeed one of the problems. Fact 1: We have users that use zope.app packages. Fact 2: We suspect many of those uses are shallow and can be shifted over to non zope.app packages. Fact 3: We don't have good maintainers for most zope.app packages. Goal 1: We don't want to maintain most zope.app packages. Goal 2: We want users to use the ZTK instead of the Zope 3.4 KGS. Goal 3: We as a community have a certain ethic of supplying backwards compatibility. Fact 4: A user can more easily shift a codebase to the ZTK if we make it easy for them with a KGS. Fact 5: A ZTK-based KGS that is a smooth upgrade from the Zope 3.4 KGS helps such users to create a working environment based on the ZTK. Goal 4: We don't want to create a large discontinuity for people using existing Zope 3 applications, Grok applications or Zope 2 applications. Goal 5: We want to maintain a KGS that helps people upgrade. Goal 6: We want to maintain such a KGS collectively if we can. Fact 6: We were maintaining such a KGS within the ZTK. Goal 7: We need a way to stop maintaining such a KGS within the ZTK. Goal 8: We need a way to stop maintaining such a zopeapp KGS altogether (unless individuals step up that want to do so) The following step was taken to accomplish goal 7 and 8. Action 1: we removed the packages we don't want to maintain from the ZTK. That accomplished goal 7 and 8, but conflicts with goal 6, 5, 3 and 2. Action 2: we move the packages we don't want to maintain from the ZTK into zopeapp. .. fulfills goal 7, and doesn't conflict with goal 6, 5, 3 and 2. It doesn't fulfill goal 8 yet, but it will help us, as a community get there, by isolating the problem. Regards, Martijn ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Lennart Regebro wrote: [snip] What difference would there be between a zopeapp KGS and a Zope3 KGS? Not much. More sharing between Grok, Zope 3 and Zope 2? Explicitly aimed at supporting backwards compatibility and upgrade path only? We've been maintaining something close to a zopeapp KGS within the ZTK until very recently. Regards, Martijn ___ 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 )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
Lennart Regebro wrote: On Tue, Dec 29, 2009 at 22:54, Martijn Faassen faas...@startifact.com wrote: Because we have a ton of installed base out there Do we? I think the debate is somewhat confused here, or possibly it's only me. :) I agree that the debate is confused. No one intends to declare that zope.app is dead. However, dropping zope.app from ZTK is a declaration that newcomers to ZTK will not have to learn anything in zope.app in order to become productive, which is a big win IMHO. Shane ___ 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 )
Re: [Zope-dev] moving the zope.app.* packages out of the ZTK: towards a plan
Hey, Martijn Faassen wrote: Let me sketch out some ideas for a plan: * we create a new project, zopeapp, with the same structure as the zopetoolkit (sans documentation) I've created such a project here, based on the zope.app* stuff that was in the ZTK. http://svn.zope.org/Sandbox/faassen/zopeapp/ * we pull the zope.app.* packages from the ZTK and move them into zopeapp. That's what I just did. zopeapp currently relies on this ZTK branch: http://svn.zope.org/zopetoolkit/branches/faassen-smaller/ which is effectively Hanno's version. In retrospect I should have just gone for this right away instead of reverting stuff. We haven't had a lot of attention from a lot of people in this discussion yet, so we'll give it a few more days (it being the holiday season). I propose we aim for going back to Hanno's trunk again sometime next week, depending on how the discussion proceeds. * we make sure we have a way to regularly run the zopeapp tests in conjunction with the ZTK. I have a link to the faassen-smaller branch from zopeapp, so it at least can stay in sync. We need to hook this stuff in some buildbot and/or make sure someone checks it for breakage. The rest of the plan still needs dates and stuff, and documentation written. That's mostly ZTK 1.0 release planning (with some backwards compatibility provisions) Regards, Martijn ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hanno Schlichting wrote: On Tue, Dec 29, 2009 at 9:54 PM, Martijn Faassen faas...@startifact.com wrote: And let's please not turn this around: I'm not putting anything *in*. Something was *removed*. Let's remove it responsibly. Not just disclaim responsibility and drop it all. So far I defined the ZTK based on what we wrote on http://docs.zope.org/zopetoolkit/about/coreextra.html. I never considered those zope.app packages to be part of the ZTK. For me that was only a technical implementation detail on how to actually get to something that fullfils those criteria about core packages. That document should've helped clue you in about this too: The Zope Toolkit Steering Group is the final arbiter of which libraries are in Zope Toolkit or not. The idea was not to have unilateral decisions about this but to have some discussion first. I think dropping lots of libraries counts as something we need to talk about before it happens. Again, I'm fine with the *goal* of making the ZTK those packages, but we can't just leave the rest behind. But it seems our understanding is different and you want the responsibility of moving Zope 3 users over to the ZTK to be the responsibility of the ZTK. I don't agree with that, but that's my problem :) The ZTK cannot be an excuse to just drop support for a large part of the existing users of the ZTK. It's a *means* to do so. What existing users does the ZTK have? I count exactly *one* user, the Zope2 trunk (until Hanno backed it out). Everybody else is using some set of packages with a more-or-less sizable intersection with the ZTK, but with no explicity dependency on the ZTK manifest at all. To be able to make more actual progress I moved Zope2 off the toolkit for now and we'll continue on our own. If at some point the ZTK offers a package set, that is actually anywhere close to what Zope2 uses, we can consider using it again. From my Zope2/Plone perspective I'm just not interested at all in any zope.app code anymore. The irony is that almost nobody is, including myself. That isn't ironic, because we were all fully aware of it: it does make your point absurd, however. But the situation is also that you as Zope 2 developers have a plan to support users that do still depend on zope.app code. Why don't you throw that plan into the wider group of people here? Because it is not relevant? Zope2 does *not* intend to provide convenience dependencies for BBB purposes, nor does Zope2 have any plans for testing the no-longer-included packages in conjunction with those which are included: apps / frameworks which want to move to Zope 2.13 will need to pull in those dependencies themselves, and do any appropriate maintenance / testing of them. If that strategy works for the ZTK, then there is no reason to revert it to include zope.app.*. We have a shared problem of backwards compatibility, right? Wrong. The strategy used for Zope2 was to eradicate use of those packages, and to ship 2.13 in a configuration which doesn't include them in any fashion. Zope2 apps or frameworks which need zope.app pacakges must declare those dependencies explicitly, and assume the burden of maintaining / pinning appropriate / compatible versions. Perhaps less for Zope 2 than for other Zope Toolkit using systems, as you never used the UI or the content types. You keep asserting a backward compatibility problem, but haven't defended it with any evidence. Be specific: who is hurt by the removal of packages from the ZTK? - - You can't claim that Grok users are so hurt: they have their own KGS, and have not yet made a committment to use the ZTK, where commitment means doing the work required to define their superset of packages as a delta to the ZTK. Instead, the Grok versions.cfg file contains a *copy* of some version of the ZTK, including a bunch of zope.app packages. It isn't even clear which of the zope.app packages are genuinely needed by Grok, as opposed to being copied in wholesale. Grok's existing test infrastructure drives of that versions.cfg file, and is so insulated from any changes to the ZTK. - - The Zope3 crowd has again gone mostly silent, but their KGS setup doesn't depend on the ZTK in anyway. The big majority of the zope.app packages are *only* interesting to this group, and will likely only be maintained by this group. - - Potential future users of the zope.app packages? Removing them from the ZTK is actually beneficial to those users, because it signals their relatively narrow focus and usefulness, as well as removing any implied proomise that they are being actively maintained by the wider Zope communtiy. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Design
Re: [Zope-dev] zope.testing 3.8.6 emits deprecation warnings from itself?
Marius Gedminas wrote: * Meanwhile there are discussions about issues switching from old zope.testing.doctest to stdlib's doctest with Windows and newlines. * I'd rather revert back the state of things as of zope.testing 3.8.4 with the legacy zope.testing.doctestunit imports added back and a single deprecation warning for zope.testing.doctestunit, until we figure out the difficult part: what to do with zope.testing.doctest itself. Yes please! For me, this likely means getting the Windows newline stuff fixed and in a Python 2.x release *before* deprecating zope.testing.doctest! Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] zope.testing 3.8.6 emits deprecation warnings from itself?
On Tue, Dec 29, 2009 at 10:55:37PM +0100, Fabio Tranchitella wrote:
* 2009-12-29 21:54, Marius Gedminas wrote:
* Fabio Tranchitella is working to make the zope.testing.doctest
deprecation warning useful by doing scary things like converting
zope.testing.doctest from a module into a package that has all the
code in __init__.py. He asked for a review of his changes. I'm too
scared to do that.
* Meanwhile there are discussions about issues switching from old
zope.testing.doctest to stdlib's doctest with Windows and newlines.
Note that the current trunk of zope.testing is already using the standard
doctest; zope.testing.doctest is still there for backward compatibility,
and emits a single deprecation warning at import time. We were considering
about switching to a deprecation warning issued at each usage of
zope.testing.doctest.{DocFileSuite,DocTestSuite}, though.
I tested the whole ZTK (hey, with the zope.app.* packages too :)) and
there were no regressions.
That's kinda reassuring, but ZTK is a (small) subset of packages that
rely on zope.testing.
I don't know enough about the differences between stdlib's doctest.py
(in its various Python 2.4/2.5/2.6 incarnations) and
zope.testing.doctest, other than that I've seen diffs, they were
non-trivial, with bugfixes and new features; I've heard about
monkey-patching the stdlib's doctest.py (which fills me with dread; when
exactly is the monkey-patching performed?), and I'd rather not touch the
issue without either complete understanding or a very large test suite
(all of the packages that were in the Zope 3 KGS at the very least) run
on various platforms.
I'd love if somebody would review my changes, though, and help me to make a
release.
Where are the changes, again? Are you talking about r107023?
http://zope3.pov.lt/trac/changeset/107023/zope.testing/trunk
Ah, I understand the point of putting code into __init__.py now!
Clever.
+1 for all the changes, but AFAICS if people move from
zope.testing.doctest to stdlib's doctest they lose at least two things:
* custom doctest exception formatting
* support for the INTERPRET_FOOTNOTES feature
and since zope.testing.doctest still reimplements large bits of doctest,
I don't know what other bugfixes might be lost too (like the universal
newline thing that punishes people for daring to release packages from
Windows machines).
Overall, I'm still -1 for deprecating zope.testing.doctest at this point.
A PendingDeprecationWarning would be more appropriate, IMHO.
Cheers!
Marius Gedminas
--
http://pov.lt/ -- Zope 3 consulting and development
signature.asc
Description: Digital signature
___
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 )
Re: [Zope-dev] removing zope.app from the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: On Tue, Dec 29, 2009 at 4:04 PM, Martijn Faassen faas...@startifact.com wrote: But right now we need to provide some guidance for how people can move away from these packages in a sane manner. And we should make sure we continue to test the zope.app.* packages when we make ZTK changes, for the time being. Let's work out a plan and a timeline. I think we disagree as to the scale of what's needed still. I'd be happy to see a copy of the ZTK tree get made to some recognizable name (ZATK, for Zope App Toolkit, would suffice), let Hanno commit his removal of the zope.app packages from the ZTK, and then make the ZATK refer to that version of the ZTK instead of including it directly. The only timeline that's needed is the order of the commits. If there's anyone who wants to maintain the new bastard-stepchild, they're free to step forward. There's no obligation on the part of the ZTK maintainers to do that, nor should there be. That's the whole point. +1. My feelinge exactly. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks6hrkACgkQ+gerLs4ltQ6CSQCgtrMQVOADLC9vXX8LKK3gN+mi n94AoLlMSpZsuXRom3G2FOapPHkxw0AC =UMmW -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] Zope 2.12.2 SyntaxError on installation
Marius Gedminas wrote: Or we could put a sample zope.conf somewhere on the web (heck, in svn is fine, using those nice *checkout* urls we've already used for downloading buildout's bootstrap.py or the Zope 2.12.2 versions.cfg). Sphinx also supports the ability to insert a link to a file. Maybe put the complete zope.conf as a link below the example start-of-zope.conf? It'd be even better if there was a command I could run to generate an up-to-date default zope.conf, like mkzopeinstance does. Is there one? In my dreams, I wanted a (waves hands something like) buildout recipe that would: - take a skeleton - zip it up - put that zipped data and some unpacking code into a single .py file For me, the skeleton would be a zope2 buildout instance containing: - bootstrap .py - a minimal buildout.cfg - some empty directories for logs, var, etc, etc Sadly, that instancebuilder script/recipe is likely to remain a dream :-( Now the using buildout section of INSTALL.rst leaves the user to write one completely from scratch Anyone using that section of the docs should be happy doing that ;-) without any tool support or even a link to documentation, and I'd like to fix this in case I have to set up a Zope 2.x instance ever again ;-) You know where the skeleton zope.conf lives though... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] Zope 2.12.2 SyntaxError on installation
Hanno Schlichting wrote: Well, either you use mkzopeinstance, which indeed generates an instance for you with all things included, or if you use buildout you use a recipe like plone.recipe.zope2instance, in which case all it takes is: [instance] recipe = plone.recipe.zope2instance eggs = Zope2 user = admin:password http-address = 127.0.0.1:8080 Yes, but this recipe is overly burdensome and unnecessary in its desire to spew out out. It's also obnoxious to have to manage your zope.conf through a limited set of config options to a recipe. I wish there was something like zc.zodbrecipes for Zope 2... ...especially if it used deployments. The current buildout docs are aimed at people who know how to set up Zope2 and don't want any help. Those are comfortable reading ZConfig definition files. ...or the skeleton files that ship with the Zope 2 egg. cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] Zope 2.12.2 SyntaxError on installation
On Tue, Dec 29, 2009 at 11:28 PM, Marius Gedminas mar...@gedmin.as wrote: What do y'all Zope-2-maintainer-people think about this patch? [...] Looks good. I'll take that as a +0. Please do. Thanks, Hanno ___ 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 )
Re: [Zope-dev] Zope 2.12.2 SyntaxError on installation
Hanno Schlichting wrote: To be honest the reason that recipe isn't mentioned there, is because Chris Withers worked on that section and didn't feel like it belongs there. And nobody else cared a great deal. Exactly. That section is for people who are moving existing Zope instances to 2.12, and they already have zope.conf's... Note that plone.recipe.zope2instance is actually in the collective, has a bug tracker on Launchpad and is licensed under the ZPL 2.1. The namespace plone just signals written by the Plone community. ...run away! ;-) Do you think that's how it should be, or would you like to improve the situation for Zope 2.13 (or even 2.12.3)? I actually don't care about that specific piece of documentation. There's hardly ever new users to Zope 2 that'd need it. Agreed. I certainly don't want to encourage new users to Zope 2. Do you think a command such as my suggested 'zopectl init' would be convenient for both new and advanced users? zopectl init would be highly confusing. The zopectl script is usually associated with a particular Zope instance. That instance should have been created beforehand. Agreed. Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] Zope 2.12.2 SyntaxError on installation
Marius Gedminas wrote: What do y'all Zope-2-maintainer-people think about this patch? Index: doc/INSTALL.rst === --- doc/INSTALL.rst (revision 107265) +++ doc/INSTALL.rst (working copy) @@ -136,11 +136,16 @@ command-line options, run the script wit Creating a buildout-based Zope Instance === -If you wish to use buildout to manage your Zope instance, then the +If you wish to use buildout to manage your Zope instance, there are recipes +like `plone.recipe.zope2instance`__ that automate everything. + + __ http://pypi.python.org/pypi/plone.recipe.zope2instance + +If you're a power user and want to drop to the basics, then the instance is created as follows: * Create a directory for your instance. In this directory, create a - ``etc``, ``logs`` and ``var`` subdirectories. + ``etc``, ``log`` and ``var`` subdirectories. * Download the following file into your instance directory: @@ -186,6 +191,8 @@ used. instancehome $INSTANCE + rest of the stuff that goes into a zope.conf, e.g. databases and log files. + .. highlight:: bash + 0.5 from me. Exist, for one. I don't have a bin/mkzopeinstance when I follow the instructions here: http://docs.zope.org/zope2/releases/2.12/INSTALL.html#buildout-instances ...that's because that gives you an instance, and if you have an instance you don't need mkzopeinstance ;-) mkzopeinstance is covered further up on that page, where a user who didn't know what buildout is would find it first :-P Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] zope.testing 3.8.6 emits deprecation warnings from itself?
Marius Gedminas wrote: +1 for all the changes, but AFAICS if people move from zope.testing.doctest to stdlib's doctest they lose at least two things: * custom doctest exception formatting * support for the INTERPRET_FOOTNOTES feature and since zope.testing.doctest still reimplements large bits of doctest, I don't know what other bugfixes might be lost too (like the universal newline thing that punishes people for daring to release packages from Windows machines). Not even release, develop and test... Overall, I'm still -1 for deprecating zope.testing.doctest at this point. A PendingDeprecationWarning would be more appropriate, IMHO. I'm -sys.maxint, lets not have the zLOG debacle over again... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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 )
[Zope-dev] Zope 3.4 and the way forward
So, what's the way forward for existing Zope 3.4 (KGS) users? Rewrite our apps so we don't depend on anything in zope.app and switch to the ZTK? Band together and release a Zope 3.5 KGS, which would be a strict superset of the ZTK 1.0? Band together and release a ZopeApp 1.0 KGS which would be a strict superset of the ZTK 1.0? (In which case, why not call it Zope 3.5 KGS?) Forget all this open-source sharing stuff and maintain our own separate versions.cfg files with ad-hoc version mixes? Personally, I'd prefer option 1 (if there were docs to tell me what to do to get rid of zope.app, which is implausible) or option 2. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ 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 )
Re: [Zope-dev] moving the zope.app.* packages out of the ZTK: towards a plan
On Tue, Dec 29, 2009 at 4:19 PM, Martijn Faassen faas...@startifact.com wrote: Let me sketch out some ideas for a plan: Thankfully you started getting this done while I was distracted from my email by a meeting. :-) I'll send this anyway, since there's probably a few points of contention still, though I don't think they're large or difficult to work out. * we create a new project, zopeapp, with the same structure as the zopetoolkit (sans documentation) +1 * we pull the zope.app.* packages from the ZTK and move them into zopeapp. +1 * we make sure we have a way to regularly run the zopeapp tests in conjunction with the ZTK. -1 (not the problem of the ZTK maintainers; anyone who cares can start from the machinery used for the ZTK, if they exist) * we then move towards a release of ZTK 1.0 (see Hanno's mail for lots of things we need to work out) +1 * we also release zopeapp 1.0 in conjunction with it. This is just a backwards compatibility KGSish thing. We explicitly don't strive to document it, etc. -1 (again, not the problem for the ZTK maintainers; let's let someone who cares worry about what constitutes 1.0 or any other release) * we announce that we strive to deprecate what's in zopeapp 1.0 and that we expect users to shift to use ZTK packages as much as possible and report back any difficulties they have with this. -1 (let those who care about the packages in the fledgling zopeapp decide what to do with them) * this will help us determine whether there is still useful code left in zopeapp that we wish to salvage into the ZTK or otherwise maintain. -1 (no need) * this will also help us determine which packages in zopeapp are more generally useful, and strive to isolate them from the rest of zopeapp. zope.formlib is an example of this. Packages not in the ZTK can be considered for adoption into the ZTK based on the policies of ZTK maintenance; no need for a separate review step as part of splitting things up. * depending on our experiences in Zope 2, Zope 3 and Grok apps we can decide whether we can put zopeapp in the deep freeze: not maintain it anymore. +1 that it's not a ZTK issue. There's no action for the ZTK maintainers in this. * we then also look into shunting away the zope.app.* packages from the top-level SVN into an this is old stuff area by that time. -1 (no need) Note that we also have a long-standing idea of a wider KGS which contains the ZTK plus perhaps zopeapp plus more, such as z3c.form. This is a related exercise. Again, this isn't a ZTK issue, but a consideration for those interested in those higher-level projects. Once we have some discussion we can hopefully flesh out this plan, put in some dates and such, and put the plan in the Zope Toolkit documentatino. -1 (such projects should not be incorporated into the ZTK project) -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Tres Seaver wrote: Martijn Faassen wrote: [snip] The ZTK cannot be an excuse to just drop support for a large part of the existing users of the ZTK. It's a *means* to do so. What existing users does the ZTK have? I'll rewrite that: The ZTK cannot be an excuse to just drop support for a large part of the existing users of packages that are in the ZTK, namely the users of Zope 3.4. It's a means to do so. We have three perspectives: * the ZTK is new, therefore the ZTK doesn't need to care about Zope 3 at all. * the ZTK is a renamed, refocused Zope 3, therefore the ZTK needs to care about Zope 3. * both: the ZTK is a way for us to stop caring about Zope 3, given some work. I'm in the both camp. This is a transition problem. I'm arguing in favor of handling this transition properly. I count exactly *one* user, the Zope2 trunk (until Hanno backed it out). Everybody else is using some set of packages with a more-or-less sizable intersection with the ZTK, but with no explicity dependency on the ZTK manifest at all. The Grok 1.1 alphas are based on a slightly older version of the ZTK. (I see you discount this as proper use of the ZTK below) [snip] Because it is not relevant? Zope2 does *not* intend to provide convenience dependencies for BBB purposes, nor does Zope2 have any plans for testing the no-longer-included packages in conjunction with those which are included: apps / frameworks which want to move to Zope 2.13 will need to pull in those dependencies themselves, and do any appropriate maintenance / testing of them. If that strategy works for the ZTK, then there is no reason to revert it to include zope.app.*. Okay. I wonder how that's going to work out for the Zope 2 users. I think a zopeapp KGS that will help them transition existing code from Zope 2.12 to Zope 2.13 in working condition would be helpful to Zope 2 users. We have a shared problem of backwards compatibility, right? Wrong. The strategy used for Zope2 was to eradicate use of those packages, and to ship 2.13 in a configuration which doesn't include them in any fashion. Zope2 apps or frameworks which need zope.app pacakges must declare those dependencies explicitly, and assume the burden of maintaining / pinning appropriate / compatible versions. Why not maintain such a list together instead of letting everybody figure this out themselves? It's not always easy to make sure you have the right packages. We were maintaining this list together, until very recently. For instance, with Grok, we had a situation where we were using a newer version of zope.app.container by accident, thus pulling in zope.container in a Zope 3.4 situation. With Zope 2 I can see the reverse situation, where someone accidentally pins a version of zope.app.container that doesn't yet depend on the zope.container implementation. A KGS can help there., Perhaps less for Zope 2 than for other Zope Toolkit using systems, as you never used the UI or the content types. You keep asserting a backward compatibility problem, but haven't defended it with any evidence. Be specific: who is hurt by the removal of packages from the ZTK? Everybody who uses any previous KGS, once they upgrade their codebases to use the ZTK. Unless they can pull in the extended list of zope.app packages, so that they can upgrade their app without having to assemble a working list of ZTK compatible versions themselves. (and then they can go and remove the zope.app dependencies) - - You can't claim that Grok users are so hurt: they have their own KGS, and have not yet made a committment to use the ZTK, where commitment means doing the work required to define their superset of packages as a delta to the ZTK. Instead, the Grok versions.cfg file contains a *copy* of some version of the ZTK, including a bunch of zope.app packages. It isn't even clear which of the zope.app packages are genuinely needed by Grok, as opposed to being copied in wholesale. Grok's existing test infrastructure drives of that versions.cfg file, and is so insulated from any changes to the ZTK. To copy a ZTK list is just a technical decision because we cannot rely on a released version of the ZTK yet. We don't want unexpected test breakage due to changes in the ZTK. We would certainly have had some unexpected breakage this week! Copying the new list without having a zope.app list known to work would present us with a problem. Grok 1.1 is slated to use the ZTK (perhaps again by copying the ZTK list). (Grok's need to have cleaner dependencies provided a large amount of the initial momentum into the ZTK project) Regards, Martijn ___ 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 )
Re: [Zope-dev] Zope 3.4 and the way forward
Hey, Marius Gedminas wrote: So, what's the way forward for existing Zope 3.4 (KGS) users? Rewrite our apps so we don't depend on anything in zope.app and switch to the ZTK? That's not possible as far as I can see, as the Zope 3.4 KGS doesn't support this. No zope.container yet, for instance, so no way to get rid of zope.app.container. It's only possible to start such an app rewrite once you're on the ZTK. (we don't know whether it's possible to complete such a rewrite. we will have to see) Band together and release a Zope 3.5 KGS, which would be a strict superset of the ZTK 1.0? Band together and release a ZopeApp 1.0 KGS which would be a strict superset of the ZTK 1.0? Yes. Possibly a Zope 3.5 KGS that extends that further, I'm not sure. (In which case, why not call it Zope 3.5 KGS?) Because Grok can use the ZopeApp 1.0 KGS as well. So can Zope 2 users who need to upgrade away from zope.app packages. (I think!) Forget all this open-source sharing stuff and maintain our own separate versions.cfg files with ad-hoc version mixes? I'm trying to remember this open source sharing stuff and avoid ad-hoc version mixes where we can. Personally, I'd prefer option 1 (if there were docs to tell me what to do to get rid of zope.app, which is implausible) or option 2. I prefer option 3 (ZopeApp KGS), because there's a greater opportunity for that old open source sharing thing. And also because it would help us get rid of the somewhat confusing Zope 3 terminology. Regards, Martijn ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Tue, Dec 29, 2009 at 6:11 PM, Martijn Faassen faas...@startifact.com wrote: * the ZTK is new, therefore the ZTK doesn't need to care about Zope 3 at all. I'm strongly in this camp. The other camps can readily be supported on top of this view of the ZTK by providing new names for higher-level toolkits and applications. Without the scope reduction on the ZTK, there's not really any motivation for it. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: We have three perspectives: * the ZTK is new, therefore the ZTK doesn't need to care about Zope 3 at all. +1 * the ZTK is a renamed, refocused Zope 3, therefore the ZTK needs to care about Zope 3. - -1 * both: the ZTK is a way for us to stop caring about Zope 3, given some work. - -1 I think a zopeapp KGS that will help them transition existing code from Zope 2.12 to Zope 2.13 in working condition would be helpful to Zope 2 users. I do not believe there is any meaningful group of people who would be catastrophically affected by not having this transition become part of the ZTK's responsibilities. You keep asserting a backward compatibility problem, but haven't defended it with any evidence. Be specific: who is hurt by the removal of packages from the ZTK? Everybody who uses any previous KGS, once they upgrade their codebases to use the ZTK. Unless they can pull in the extended list of zope.app packages, so that they can upgrade their app without having to assemble a working list of ZTK compatible versions themselves. (and then they can go and remove the zope.app dependencies) Again, I doubt there is any meaningful number of people falling into this group. jens P.S.: I'm watching on the sidelines because I consider myself much more of a simple Zope 2 user than someone who has valid input for the ZTK per se. I just don't grok (pun intended) any of these assertions that the ZTK has any responsibility for providing a stepping stone for zope.app.*-package users. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAks6kAAACgkQRAx5nvEhZLLo9ACfWKWew8mTwkW5DFRx4E9UCwQJ nPQAoI6s1s5D3IiOC3bHSGJibNDwQUUs =ARZn -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] moving the zope.app.* packages out of the ZTK: towards a plan
Hi there, Fred Drake wrote: On Tue, Dec 29, 2009 at 4:19 PM, Martijn Faassen faas...@startifact.com wrote: Let me sketch out some ideas for a plan: [snip] * we make sure we have a way to regularly run the zopeapp tests in conjunction with the ZTK. -1 (not the problem of the ZTK maintainers; anyone who cares can start from the machinery used for the ZTK, if they exist) [snip] * we also release zopeapp 1.0 in conjunction with it. This is just a backwards compatibility KGSish thing. We explicitly don't strive to document it, etc. -1 (again, not the problem for the ZTK maintainers; let's let someone who cares worry about what constitutes 1.0 or any other release) [snip] Note that we also have a long-standing idea of a wider KGS which contains the ZTK plus perhaps zopeapp plus more, such as z3c.form. This is a related exercise. Again, this isn't a ZTK issue, but a consideration for those interested in those higher-level projects. I agree with these -1, but only from the perspective of the future, not from the perspective of the transition we're in. These are ZTK issues only in as much as that these are issues of the users of the ZTK, just like any other users of the ZTK. The ZTK developers should not have to maintain other KGSes. Once we have some discussion we can hopefully flesh out this plan, put in some dates and such, and put the plan in the Zope Toolkit documentatino. -1 (such projects should not be incorporated into the ZTK project) This is a problem for the zope-dev community, which includes the ZTK maintainers. So however we want to make responsible, as a zope-dev community we are still responsible. I will now argue why I think this is a particular responsibility for the ZTK maintainers at this time. This is because it is a transition problem. I am assuming that the ZTK maintainers want to attract users to the ZTK. One important class of users is the existing users we have of libraries in this toolkit. In fact this is realistically speaking almost all the people on the ZTK in the near future, until we vastly improve documentation. It makes sense to help these people to transition onto the ZTK, as the ZTK without users is pointless. So I'm proposing we incorporate the zopeapp project as a project with an *explicitly limited responsibility* within the ZTK project *for a limited period of time*, during the phase of transition, to assist people to upgrade to use the ZTK within their project. After the transition phase, which we should clearly communicate, the ZTK maintainers have a responsibility to the zopeapp project in the same way as they have a responsibility to other projects that use the ZTK. So, after the transition, zopeapp will cease to be a special responsibility for the ZTK maintainers. If we really care about not making ZTK maintainers responsible for this in any way, we could instead create a special transition project out of this, but that seems overkill. We could also relegate it to the inactive Zope 3 development community we were trying to fix in the first place.. Regards, Martijn ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Wed, Dec 30, 2009 at 12:11 AM, Martijn Faassen faas...@startifact.com wrote: I think a zopeapp KGS that will help them transition existing code from Zope 2.12 to Zope 2.13 in working condition would be helpful to Zope 2 users. Not really. Zope 2.12 is exactly that transitionary release defining a KGS for everything that was included in Zope 2.11 (~3.4.1). We already have our version of the zopeapp KGS with that. Everyone else is free to reuse this KGS, but so far nobody was interested in it. It reflects the status of zope.*/zope.app.* a couple months back. With Plone 4 based on this KGS, we are going to maintain it for the next couple of years. It's not completely zope.app-free but close enough to make the jump to 2.13 trivial for Zope2 projects. Why not maintain such a list together instead of letting everybody figure this out themselves? It's not always easy to make sure you have the right packages. We were maintaining this list together, until very recently. The list we were maintaining together, was what I thought to be the KGS *after* the transition period. Hanno ___ 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 )
Re: [Zope-dev] Zope 2.12.2 SyntaxError on installation
On Tue, Dec 29, 2009 at 10:50:23PM +, Chris Withers wrote: Marius Gedminas wrote: Now the using buildout section of INSTALL.rst leaves the user to write one completely from scratch Anyone using that section of the docs should be happy doing that ;-) without any tool support or even a link to documentation, and I'd like to fix this in case I have to set up a Zope 2.x instance ever again ;-) You know where the skeleton zope.conf lives though... Actually, no, I don't. (I took the zope.conf from the existing Zope 2.10 instance that I was migrating to 2.12.) Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Hanno Schlichting wrote: On Wed, Dec 30, 2009 at 12:11 AM, Martijn Faassen faas...@startifact.com wrote: I think a zopeapp KGS that will help them transition existing code from Zope 2.12 to Zope 2.13 in working condition would be helpful to Zope 2 users. Not really. Zope 2.12 is exactly that transitionary release defining a KGS for everything that was included in Zope 2.11 (~3.4.1). Ah, I didn't realize Zope 2.12 was already based on an earlier version of the ZTK. Then I guess I mean zopeapp might help people transitioning from 2.11 to Zope 2.13. I don't know how many people are making that transition. We already have our version of the zopeapp KGS with that. Everyone else is free to reuse this KGS, but so far nobody was interested in it. I missed where you offered this list for more general reuse. If I'd known about it might have been useful for us working for Grok, and as a basis of zopeapp. I'm interested the current zopeapp to support the Grok transition and to help people transition Zope 3 apps. I didn't realize Zope 2 was already that far along having released earlier ZTK versions. It reflects the status of zope.*/zope.app.* a couple months back. With Plone 4 based on this KGS, we are going to maintain it for the next couple of years. It's not completely zope.app-free but close enough to make the jump to 2.13 trivial for Zope2 projects. Why not maintain such a list together instead of letting everybody figure this out themselves? It's not always easy to make sure you have the right packages. We were maintaining this list together, until very recently. The list we were maintaining together, was what I thought to be the KGS *after* the transition period. I'm not sure what you mean here. Anyway, there are now two lists in my mind: the ZTK list (yours), and the zopeapp list. Both are useful to share, though the ZTK is obviously the main goal. I was proposing zopeapp is useful for Zope 2 developers, but apparently not much as the use of the ZTK is out of sync. Regards, Martijn ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Wed, Dec 30, 2009 at 12:55 AM, Martijn Faassen faas...@startifact.com wrote: Hanno Schlichting wrote: Not really. Zope 2.12 is exactly that transitionary release defining a KGS for everything that was included in Zope 2.11 (~3.4.1). Ah, I didn't realize Zope 2.12 was already based on an earlier version of the ZTK. Then I guess I mean zopeapp might help people transitioning from 2.11 to Zope 2.13. I don't know how many people are making that transition. Not many. Zope 2.11 hasn't been in much use. Arguably the largest group of people are doing this through Plone. There the story is different again, as the lastest stable Plone release (3.3) is based on Zope 2.10 which included Zope 3.3.2. Plone 4, which should see a beta release any day now, is based on Zope 2.12 (including ZTK 0.5). We'll see a number of Plone 4.x releases, which will most likely stick to Zope 2.12. Only Plone 5 (which I happen to be release manager of) will use a new Zope 2.13. Since Plone is basically driving the Zope 2 release schedule these days, we'll likely not see a new major Zope 2 release until Plone 5 alphas are getting ready. So the two main upgrade paths we have are Zope 3.3.2 to ZTK 0.5. And then at some point in maybe 12 to 18 months a ZTK 0.5 to ZTK x.y upgrade. This also means that an actual ZTK release, that is done anywhere before late 2010 is pretty much not usable for Zope 2. If the difference between our ZTK 0.5 release and the final version gets too large and breaks backwards compatibility, we have another problem. Grok's release schedule obviously looks very different from this. And I have no idea what the schedules of any other potential users of the ZTK might look like. Agreeing on the scope and timeframe of the or many ZTK releases is going to be quite interesting in itself. I missed where you offered this list for more general reuse. If I'd known about it might have been useful for us working for Grok, and as a basis of zopeapp. I'm interested the current zopeapp to support the Grok transition and to help people transition Zope 3 apps. I didn't realize Zope 2 was already that far along having released earlier ZTK versions. Well, we did a freeze of our ZTK KGS with our Zope 2.12 beta 2 release. This happened end of May 2009. At that point Grok was a long way from having an actual 1.0 release, which only happened much later facilitated by the Neanderthal sprint in September. This whole topic wasn't really on your radar at that point. But Zope2 and Plone couldn't wait for an indefinite time, hoping that someday the ZTK would actually be ready. Hanno ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
Hanno Schlichting wrote: [snip explanation of current Zope 2 and Plone plans, thanks] So the two main upgrade paths we have are Zope 3.3.2 to ZTK 0.5. And then at some point in maybe 12 to 18 months a ZTK 0.5 to ZTK x.y upgrade. This also means that an actual ZTK release, that is done anywhere before late 2010 is pretty much not usable for Zope 2. If the difference between our ZTK 0.5 release and the final version gets too large and breaks backwards compatibility, we have another problem. ZTK 0.5 still contains zope.app.* packages, correct? Assuming ZTK x.y won't have zope.app packages, this means that those upgrading to Zope 2.13 might be helped by a list of working versions of those zope.app.* packages (such as the one in zopeapp), or am I wrong? Of course I imagine this list is quite short in your case, as you were already on ZTK 0.5. Grok's release schedule obviously looks very different from this. And I have no idea what the schedules of any other potential users of the ZTK might look like. Agreeing on the scope and timeframe of the or many ZTK releases is going to be quite interesting in itself. Yes, and agreeing about what transition support we supply seems to be even more interesting. :) I missed where you offered this list for more general reuse. If I'd known about it might have been useful for us working for Grok, and as a basis of zopeapp. I'm interested the current zopeapp to support the Grok transition and to help people transition Zope 3 apps. I didn't realize Zope 2 was already that far along having released earlier ZTK versions. Well, we did a freeze of our ZTK KGS with our Zope 2.12 beta 2 release. This happened end of May 2009. At that point Grok was a long way from having an actual 1.0 release, which only happened much later facilitated by the Neanderthal sprint in September. This whole topic wasn't really on your radar at that point. Yes, it was too early for Grok. That said, the ZTK topic has been on my radar from the start, and helping to start it we were obviously thinking about upgrading Grok to it from the start. Earlier on, we had quite a big discussion about What is the ZTK where various people were arguing for starting with a short list and building it up, versus starting with the long list and whittling it down. At the time we went with the latter. One of the motivations for the long list I believe was to help people transition better. I don't recall the splitting lists idea coming up (one main, one backwards compatibility) but that was probably because it was infeasible then given the large amount of zope.app dependencies we still had. At some point the Zope 2 developers came up with that idea as you evidently did it, but the idea didn't flow back into the ZTK at the time. Regards, Martijn ___ 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 )
Re: [Zope-dev] removing zope.app from the ZTK
On Wed, Dec 30, 2009 at 1:46 AM, Martijn Faassen faas...@startifact.com wrote: Assuming ZTK x.y won't have zope.app packages, this means that those upgrading to Zope 2.13 might be helped by a list of working versions of those zope.app.* packages (such as the one in zopeapp), or am I wrong? Of course I imagine this list is quite short in your case, as you were already on ZTK 0.5. The list is quite small indeed. There's: zope.app.appsetup zope.app.basicskin zope.app.debug zope.app.dependable zope.app.pagetemplate zope.app.publication zope.app.publisher zope.app.schema all of which don't matter, as those are just transitive dependencies but contain no code that was usable inside Zope 2. And then there's: zope.app.component zope.app.container zope.app.form zope.app.testing zope.app.component was mostly used to import the hooks getSite / setSite stuff. But we already have zope.site containing those and app.component is just a BBB shim. Almost nothing inside zope.app.container is actually used, as we have OFS and Products.BTreeFolder as the canonical folder implementations, in any case app.container is a BBB shim around container as well. zope.app.form has a bit of a special status, but we solved that by factoring out the entire formlib / app.form dependency into an extra distribution called five.formlib. Users of formlib can switch to that during Zope 2.12, in 2.13 we won't have to ship it anymore. And finally zope.app.testing had seen some uses for the ztapi stuff or test setup, but generally we have Testing and ZopeTestCase that provide the Zope2 specific versions of those. And well, that's it. Since most of the other code inside zope.app was never actually usable inside Zope 2, we don't have that much of a problem with it. Some other things are hidden behind ZCML constructs like the various browser registrations and Zope 2 takes care of loading the right meta.zcml's for you. Other stuff is hidden behind Five, which actually works to our advantage now ;) Earlier on, we had quite a big discussion about What is the ZTK where various people were arguing for starting with a short list and building it up, versus starting with the long list and whittling it down. At the time we went with the latter. One of the motivations for the long list I believe was to help people transition better. Yeah, I was a proponent of the start small approach :) Hanno ___ 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 )
