Re: [Zope-dev] component registry navelgazing
* 2011-06-12 22:49, Chris McDonough wrote: > This seems slightly inconsistent with the adaptation worldview imposed by > getAdapter/queryAdapter. I think it would be more consistent if > "c.queryAdapter(IFoo, foo)" returned foo if foo already implemented IFoo > and there was no other more specific adapter registered for the IFoo/foo > pair in the registry, no? +1, way more consistent than returning None. Regards, 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] Zope2: Reducing C dependencies
* 2010-03-30 17:44, Martin Aspeli wrote: > I'm generally for it, we just need to (a) make sure we're not going to > negatively impact performance if we can help it and (b) explain our > rationale. Not sure I understood correctly what Hanno proposed, but we are not going to negatively impact performance because we are not replacing C code with Python code, just factoring it out into an independent package. Right? Best regards. 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.component.zcml and global registry
* 2010-03-08 18:16, Fabio Tranchitella wrote: > I'll wait till the week-end to release it, so everybody has the opportunity > to have a word on this topic. I've released zope.component 3.9.3 with the change I discussed on the list in the last couple of weeks (ZCML registrations using getSiteManager instead of getGlobalSiteManager) and updated the ztk.conf. Best regards, 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] [PATCH] subunit output for zope.testing
* 2010-03-13 16:16, Marius Gedminas wrote: > I'm not entirely sure what the deprecation story is all about (well, > okay, it's about reducing the number of forks and opening the way to > Python 3 compatibility), but I'm a bit uneasy leaving it in such a > halfway state... On the other hand people worked hard on it, and I > wouldn't want to throw their work away by un-deprecating > zope.testing.doctest. As one of the people who worked hard to clean out the situation, I'm okey with the un-deprecation. Thanks, 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.component.zcml and global registry
* 2010-03-08 17:51, Roger wrote: > A bugfix probably for your app, but a feature for zope packages I thought it is a bug fix (I see no reason why it used the global registry before, because it is totally equivalent) and it does not change the API and the semantic of the ZCML directives. I don't mind releasing as a major release, though. > I hope nobody is using setSite in the wrong place, then this new feature > will horribly break their applications. TBH, I see no possibility to break anything with such a change, unless you really expect to work it in this way (eg. hooking getSiteManager *before* loading a ZCML file). I'll wait till the week-end to release it, so everybody has the opportunity to have a word on this topic. Best regards, 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.component.zcml and global registry
* 2010-03-04 20:51, Fabio Tranchitella wrote: > Committed with tests. If nobody objects, I would like to release a new (bugfix) release of zope.component with the current trunk. This is the relevant entry from the CHANGES.txt file: - The ZCML directives provided by zope.component now register the components in the registry returned by getSiteManager instead of the global registry. This allows the hooking of the getSiteManager method before the load of a ZCML file to register the components in a custom registry. Thanks, 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.component.zcml and global registry
* 2010-03-03 21:35, Tres Seaver wrote: > If the tests all pass, then I would say go ahead and commit it now, but > add tests to verify that the new feature works as you expect. Committed with tests. Best regards, 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] Uses of the ZTK and how it relates to management
Hello, * 2010-03-04 09:22, Baiju M wrote: > I wonder whether we can split ztk.cfg & zopeapp.cfg further logically ? > Something like zca.cfg , index.cfg, form.cfg, auth.cfg etc. ? May be we > will end up with one cfg file for each package :) I don't think we need to split the cfg files: IMHO what we are looking for (or should be looking for) is not a technical solution, but something to solve a management issue. Having people responsible for a subset of packages does not involve any change in our technical infrastructure, maybe just a website where to store the documentation. Anyway, this is my "idea" of fragmentation of the ZTK into self-contained reusable groups of packages, you can like it or not like, it is just an idea. :) Best regards, 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] Uses of the ZTK and how it relates to management
* 2010-03-03 21:44, Jim Fulton wrote: > The ZTK was created in part to deal with instability issues arising from > people working on parts without testing the whole. I suppose everybody here agrees that any change to a package which is part of the ZTK *must* be tested against the whole ZTK. It would be easier to nd leading developers for subgroups of packages (eg. bicycle repair kit, rm generation, ...) willing to raise the quality of a specific subset of packages instead of finding a release manager willing to oversee > 60 packages, which he does not really use (because I don't think we have a single developer using *all* of the packages in the ZTK). These specific leading developers could report and synchronize with a ZTK release manager, though. My two euro cents. 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] Stop energy
* 2010-03-03 20:41, Chris McDonough wrote: > Why wouldn't that be worked out here? Is it because you just want the > mechanics of such a project done elsewhere without having to see it > talked about on this maillist? Or is it because you disagree that it > should be done? Or... what? The main issue is related to the different use cases we have for the ZTK: some people use (or want to use) the ZTK as a monolithic set of packages that can be considered "somehow" the upgrade path from zope3 with the exclusion of zope.app.* (if possible). Others (like me and you, Chris) see the ZTK as a set of core packages (mainly the bicycle repair kit, which is not the only self-contained subset of useful packages though) plus a huge load of dependencies we are bringing forward from the "old" zope3 releases. Our points of view are totally different, and I suppose the first group of people fear that fragmentation can influence the quality and stability of the ZTK as a whole. In my opinion, we can only gain defining explicitly the bicycle repair kit if somebody is willing to maintain it (and I refer to documentation and marketing stuff, not code because it is already very stable). If this cannot be done with consensus on zope-dev, but a group of people is really interested in it, I don't think it can be or should be stopped and, TBH, I don't see how it can influence the ZTK. -- Fabio Tranchitella / Tranchitella Kft. http://tranchitella.eu 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ 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] Stop energy
* 2010-03-03 19:59, Chris McDonough wrote:
> I think it would be useful to have a discussion about grouping some Zope
> bits along functional lines for marketing purposes. This is really
> independent of any discussion about the ZTK.
I wonder if calling zope.{interface,component,schema,configuration,event}
the "bicycle repair kit" (note the absence of the word "zope"), with
explicit documentation and a dedicated website really need the approval of
the whole zope3 community.
Or, better... I don't think anybody can block John Doe to pick up a random
set of packages, give them a name and market them as a framework (or as a
reusable set of libraries) as long as the name "zope" is not used.
Am I wrong? It's free software, after all.
Best regards,
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.component.zcml and global registry
* 2010-03-03 14:57, Roger wrote: > If all kind of configuration directive processing is done before any kind > of DB root access and relevant event handling (e.g. site hook setup) this > seems fine to me. If not, then we run into troubles with the changes. I've tried the patch running the whole ztk test set (including the zopeapp test set) and there are no regressions, so I assume it is safe to apply it to the trunk. I'll wait a week to see if anybody objects to this change, then I'll commit it to the trunk. Thanks, 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.component.zcml and global registry
* 2010-03-03 15:33, Stephan Richter wrote: > Mmh, I implemented z3c.baseregistry a long time ago, which allows you to > register components into arbitrary registries. > > http://svn.zope.org/z3c.baseregistry/trunk/src/z3c/baseregistry/README.txt?rev=107147&view=auto Thanks for the link; z3c.baseregistry depends on zope.site, which depends on a lot of packages we don't use, though. Also, I think my use case it quite different, because we don't use ZODB, we rely on WSGI and we have one-python-process-multiple-applications setup. 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.component.zcml and global registry
Hello roger, * 2010-03-03 11:36, Roger wrote: > Not sure if I understand you correct. But what do you think > about the following: > > - implement a new optional attribute useLocal=True > in the directive and then configure the directive action > and make use of the (local) getSiteManager method. > > I like to use getGlobalSiteManager by default because this doesn't force > a database access and load the local site manager if the site is a local > site. I'm not sure what you mean with "doesn't force a database access and load the local site manager". This is the implementation of getSiteManager from zope.component._api: base = None @hookable def getSiteManager(context=None): global base if context is None: if base is None: from zope.component.globalregistry import base return base else: # Use the global site manager to adapt context to `IComponentLookup` # to avoid the recursion implied by using a local `getAdapter()` call. try: return IComponentLookup(context) except TypeError, error: raise ComponentLookupError(*error.args) In our use cases (ZCML registrations), context is None and thus it will simply return the global registry, without any database access. It is the equivalent of getGlobalSiteManager, but it can be hooked (note the @hookable decorator). > Could this be an alternative concept and fit? This would change the API, my proposed change is back-compatible and does not introduce any new API (because it is equivalent, indeed). Best regards, 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 )
[Zope-dev] zope.component.zcml and global registry
Hi folks, the ZCML directives in zope.component register components using the utility method handler, which looks like: def handler(methodName, *args, **kwargs): method = getattr(zope.component.getGlobalSiteManager(), methodName) In our company-specific framework (which is far far from zope3, and only uses the bicycle repair kit), we use different registries per application, similarly to repoze.bfg. Everything works, included code which relies on the zope.component's API, thanks to the hooks on getSiteManager. Those ZCML directives use the getGlobalSiteManager though, which is not hookable and thus we had to reimplement the ZCML directives we need to call getSiteManager instead of getGlobalSiteManager. By default, getSiteManager returns the global registry, so I don't see any obvious reason why the ZCML directives make use of getGlobalSiteManager. repoze.bfg, for example, reimplemented the ZCML directives as we did, but I'd love to be able to use the implementation from zope.component. Any idea? Would you kill me if I propose to change the registration handler to use getSiteManager instead? :) Thanks, 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.sendmail RFC: start background thread on ProcessStarting event
* 2010-01-28 15:56, Marius Gedminas wrote: > I recently came up with a different and perhaps a bit simpler solution: > > * make zope.sendmail not start the thread during ZCML processing, > instead make it listen for ProcessStarting events and start the > thread then. I like your approach, as long as the console script is also provided to process the queue (as it is now in 3.8.0). In any way, to keep BBB, we should ensure that users of zope.sendmail will have the thread running by default, without changing their code. Thanks. -- Fabio Tranchitella / Tranchitella Kft. http://tranchitella.eu 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ 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] Preparing a new release for zope.sendmail
Hello, * 2010-01-13 01:41, Tres Seaver wrote: > The 3.7.0 version breaks Zope 2.12, which still expects to be able to > import QueueProcessorThread from the old location. I worked around the > problem for the moment by pinning 'zope.sendmail<3.7.0', but it seems to > me that the BBB import should be kept (likely forever). I'm preparing a new release which will keep the BBB import, sorry for breaking zope 2.12 (I did not expect it to import something from zope.sendmail...). 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] Adapter registration in ZCML provides IUserPreferredCharsets lost ?
* 2010-01-11 06:25, Chris McDonough wrote: > I don't know exactly where to move this, but making zope.publisher a dep > of zope.i18n would be bad. Using conditionals (eg. have zope.publisher) in ZCML seems a good solution to me. Best regards, 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 )
[Zope-dev] Preparing a new release for zope.sendmail
Hello, I'm preparing a new major releases for zope.sendmail, merging the improvements and new features from the repoze.sendmail package. Here there is a copy of the changelog: - Removed dependency on ``zope.security``: the security support is optional, and only available if the ``zope.security`` package is available. This change is similar to the optional security support introduced in ``zope.component`` 3.8.0, and in fact it uses the same helpers. - Sort by modification time the messages in zope.sendmail.maildir so earlier messages are sent before later messages during queue processing. - Added the new parameter ``processorThread`` to the queuedDelivery ZCML directive: if False, the QueueProcessorThread is not started and thus an independent process must process the queue; it defaults to True for b/c. - Provide a console script ``zope-sendmail`` which can be used to process the delivery queue in case processorThread is False. The console script can either process the messages in the queue once, or run in "daemon" mode. The changes are quite intrusive, but fully backwards compatible. If nobody objects, i will make the new release on Sunday, the 10th. Best regards, 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.security dependency on zope.exceptions
* 2010-01-05 08:26, Fabio Tranchitella wrote: > While doing it, I'm trying to remove dependencies which are zope-specific, > to minimize the overhead for developers who are using the whole zope stack > (like me :)). Ehm, I meant who are NOT using the whole zope stack. 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 )
[Zope-dev] zope.security dependency on zope.exceptions
Happy New Year to everybody, I'm working to isolate a core set of ZTK packages which are independent from Zope and reusable outside the Zope community. One of them is zope.security, which can be used (and it is useful, indeed) with non-zope frameworks too. While doing it, I'm trying to remove dependencies which are zope-specific, to minimize the overhead for developers who are using the whole zope stack (like me :)). zope.security depends on zope.exceptions because it imports this symbol in zope.security.checker: from zope.exceptions import DuplicationError zope.exceptions defines DuplicationError as: class IDuplicationError(Interface): pass class DuplicationError(Exception): """A duplicate registration was attempted""" implements(IDuplicationError) The zope.exceptions package contains "exception interfaces and implementations which are so general purpose that they don't belong in Zope application-specific packages.", as stated by the README. I propose to make the remove the dependency between zope.security and zope.exceptions with a conditional import: * if zope.exceptions is available, use DuplicationError from it; * if it is not available, define a zope.security-specific DuplicationError (which inherits from ValueError, maybe). As using zope.exceptions only make sense if you are checking the exception type importing its interface from the zope.exceptions package, and thus depending on it, I see no risk in such a change. Thoughts? Comments? 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 )
[Zope-dev] zope.contenttype on PyPI is messed up
Can somebody please fix zope.contettype on PyPI? We had a 3.5.0 release, and somebody uploaded a 3.4.3 release which should have been 3.5.1. I don't have the rights for it. Best regards, 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?
* 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] Avoid deprecation warnings in the testrunner
* 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. 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] Avoid deprecation warnings in the testrunner
* 2009-12-25 10:23, Lennart Regebro wrote:
> Yes, we did. But now we try to get the deprecation warnings to show up in
> the correct place. And we could warn for the usage of some of the names,
> but in the message explain that doctest.py is deprecated.
What do you think about the attached patch (applied to the current trunk)?
It makes the tests quite noisy (each usage of DocTestSuite and DocFileSuite
raises a warning), but I think matches with what you wrote in the quoted
paragraph above.
Thanks,
Fabio
Index: src/zope/testing/doctest/__init__.py
===
--- src/zope/testing/doctest/__init__.py (revisione 107149)
+++ src/zope/testing/doctest/__init__.py (copia locale)
@@ -108,11 +108,6 @@
warnings.filterwarnings("ignore", "is_private", DeprecationWarning,
__name__, 0)
-# Tell people to use the builtin module instead.
-warnings.warn('zope.testing.doctest is deprecated in favour of '
- 'the Python standard library doctest module', DeprecationWarning,
- stacklevel=2)
-
class UnusedFootnoteWarning(Warning):
"""Warn about a footnote that is defined, but never referenced."""
@@ -2381,6 +2376,9 @@
A set of doctest option flags expressed as an integer.
"""
+warnings.warn('zope.testing.doctest is deprecated in favour of the Python '
+'standard library doctest module', DeprecationWarning, stacklevel=2)
+
if test_finder is None:
test_finder = DocTestFinder()
@@ -2512,6 +2510,9 @@
encoding
An encoding that will be used to convert the files to unicode.
"""
+warnings.warn('zope.testing.doctest is deprecated in favour of the Python '
+'standard library doctest module', DeprecationWarning, stacklevel=2)
+
suite = unittest.TestSuite()
# We do this here so that _normalize_module is called at the right
___
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] Avoid deprecation warnings in the testrunner
* 2009-12-25 07:32, Lennart Regebro wrote: > On Thu, Dec 24, 2009 at 14:50, Fabio Tranchitella wrote: > > I don't think we can avoid the error, and to be honest I consider the code > > in zope.minmax to be wrong. > > > > """ > > import zope.testing > > x = zope.testing.doctest.DocTestFile(... > > """ > > > > The import is wrong > > No, that's perferctly correct code and not wrong in any way. It is not wrong from a syntax point of view, but it is wrong because it assumes doctest is a sub-module and not a sub-package. As said here: http://docs.python.org/tutorial/modules.html#packages It would have been perfect to write: import zope.testing.doctest ... avoiding the "embedded" design decision that doctest is a sub-module. Anyway, I'm happy with whatever fix we apply, as long as we find a way to not rise the deprecation warning just after an import of zope.testing or a run of the testrunner. > What if we hide the warning during the __init__.py import. Will it > show up the next time, then? No, because modules/packages are imported only once. > Maybe we can add deprecations only for the major names in doctest.py? > That would still raise an error everytime you use it, but only when you > import a name, not the module. I thought we deprecated the whole zope.testing.doctest. Best regards, and Merry Christmas. 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] Avoid deprecation warnings in the testrunner
* 2009-12-24 16:20, Zvezdan Petkovic wrote: > Before I release the egg on PyPI: > > 1. Should we release as 1.1.2 (a minor change), or > 2. Does the removal of dependency on zope.testing warrants a > bump to 1.2.0? I think 1.1.2 is okey, you are not changing any behaviour of the package. > FWIW, I preferred zope.testing.doctest reporting of 15 tests because > that's the actual number of things being tested in that file, while > Python doctest reports 1 test only, because that's a number of test files > being run. Me too, maybe we should push the changes to doctest upstream to Python? Best regards, 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] Avoid deprecation warnings in the testrunner
* 2009-12-24 11:40, Lennart Regebro wrote: > On Thu, Dec 24, 2009 at 08:26, Fabio Tranchitella wrote: > > I've tested the whole ZTK KGS using the current zope.testing's trunk and > > the only failing package was zope.minmax (already fixed in the trunk), > > because it imported zope.testing and used zope.testing.doctest, which fails > > now that doctest is a directory and not a file, as Lennnart pointed out. > > It does? Yes, definitely. > But the code is moved to doctest/__init__.py. That should work... No, it does not because now doctest is a package. > Or maybe we need to do an import doctest from zope/testing/__init__.py > for it to show up, I don't remember. Yes, you are right, but if I'd do that, the deprecation warning would be raised by the simple import of zope.testing, making it useless because it would mask the warnings related to the package you are running the tests for. > Can we avoid this error? The whole point with the deprecation is to > NOT break code. ;) I don't think we can avoid the error, and to be honest I consider the code in zope.minmax to be wrong. """ import zope.testing x = zope.testing.doctest.DocTestFile(... """ The import is wrong, it should be "zope.testing.doctest", and I fixed it in the trunk, and this was the only failure in the ZTK. Thanks for your support, 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] Avoid deprecation warnings in the testrunner
* 2009-12-24 07:12, Lennart Regebro wrote: > Yeah, that's fine by me. I see you did some ugly hacks to make it work > like making doctest.py into directory, but I don't have a problem with > that personally. I've tested the whole ZTK KGS using the current zope.testing's trunk and the only failing package was zope.minmax (already fixed in the trunk), because it imported zope.testing and used zope.testing.doctest, which fails now that doctest is a directory and not a file, as Lennnart pointed out. I think we should now make a new release for zope.testing and, obviously, zope.minmax. I don't have the rights on PyPI, can somebody help me (or add me, kobold)? Thanks, 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] Avoid deprecation warnings in the testrunner
* 2009-12-23 22:48, Lennart Regebro wrote: > OK, I'm tired. It's only a major undertaking if you remove it completely. > zope.testings tests are mostly a question of running tests. Those should > obviously still use zope.testing.doctest, and then it's a much smaller > problem. This is exactly what I did in the trunk: zope.testing.doctest is still there (so you can use it for declaring your doctests) it is not used directly by the testrunner anymore because it uses the stdlib doctest. Best regards, 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 feature creep in release (WAS: zope.testing.doctestunit and BBB)
* 2009-12-23 16:13, Benji York wrote: > As for having a broken trunk: I believe that every project needs a head > maintainer that feels personally responsible for the state of a > particular project. They would be in charge of reviewing and approving > branches before they are merged to the project trunk. +1, we should make explicit who is responsible for which package. Zope2, Plone and other projects have the concept of "release manager", we don't have anybody responsible for the ZTK as a whole nor for a subset of the packages. 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] Avoid deprecation warnings in the testrunner
I was (finally) able to patch zope.testing to use the standard Python doctest module while still supporting zope.testing.doctest if a package is importing and using it. The tests of zope.testing are passing on Python 2.4, 2.5 and 2.6 and the output from running the tests of a package which does not make use of zope.testing.doctest doesn't contain any deprecation warning, yay! I committed my changes to the trunk. I'd appreciate if somebody would check the diff and, if nobody object, upload a new release of zope.testing (I don't have the rights on PyPI, my nickname is kobold). Best regards. Fabio * 2009-12-23 14:38, Fabio Tranchitella wrote: > ... ___ 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] Avoid deprecation warnings in the testrunner
Hello,
* 2009-12-23 14:33, Marius Gedminas wrote:
> > @@ -328,6 +327,9 @@
> > def format_traceback(self, exc_info):
> > """Format the traceback."""
> > v = exc_info[1]
> > +warnings.simplefilter('ignore')
> > +from zope.testing import doctest
> > +warnings.filters.pop()
>
> I'm not thrilled.
Me neither, but if I don't do that, I will have a lot of test failures
because the deprecation warning will be printed in the middle of the tests.
> Can we 'import doctest' from the stdlib, and hope that these isinstance
> checks work fine?
No, it doesn't because the first if is about an exception which is
zope.testing.doctest-specific.
> Specifically, can we make it so that zope.testing.doctest's exceptions
> _inherit_ from stdlib's doctest exceptions?
I couldn't find the way to do it.
> > ===
> > --- src/zope/testing/testrunner/doctest.py (revisione 106999)
> > +++ src/zope/testing/testrunner/doctest.py (copia locale)
> > @@ -17,10 +17,11 @@
> > """
> >
> > import sys
> > -from zope.testing import doctest
> > import zope.testing.testrunner.feature
> >
> > +from zope.testing import doctest
> >
> > +
>
> Doesn't seem like much of a change ;)
> Suggest importing stdlib here as well.
Same reason, we cannot use the standard doctest because it doesn't have
the feature needed there.
> > -self.features.append(zope.testing.testrunner.doctest.DocTest(self))
> > +if options.ndiff or options.udiff or options.cdiff or \
> > + options.report_only_first_failure is not None:
> > +from zope.testing.testrunner.doctest import DocTest
> > +self.features.append(DocTest(self))
>
> A *strong* -1 for this bit.
This is the only way I could avoid deprecation warnings for a test that
doesn't need zope.testing-specific doctest features. Better ideas?
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 )
[Zope-dev] Avoid deprecation warnings in the testrunner
Hello,
I think we should provide a zope.testing package which does not emit
deprecation warnings while running the testrunner on other packages,
otherwise there is no way to really understand why the package you are
working on is using a deprecated API.
I propose the patch attached to this message to zope.testing.
It tries to avoid importing zope.testing.doctest unless it is really
needed. In this way, developers can see the DeprecationWarning with the
path of *their* code, and fix it, instead of receiving the
DeprecationWarning because the testrunner imports zope.testing.doctest
itself.
Before applying the patch, running the tests on another package produced
this output:
---
.../zope/testing/testrunner/debug.py:23: DeprecationWarning:
zope.testing.doctest is deprecated in favour of the Python standard library
doctest module
from zope.testing import doctest
Running zope.testing.testrunner.layer.UnitTests tests:
...
---
After applying my patch, I get this:
---
.../zope/interface/tests/test_adapter.py:405: DeprecationWarning:
zope.testing.doctest is deprecated in favour of the Python standard library
doctest module
from zope.testing import doctest
Running zope.testing.testrunner.layer.UnitTests tests:
...
---
Comments?
Thanks,
Fabio
Index: src/zope/testing/testrunner/formatter.py
===
--- src/zope/testing/testrunner/formatter.py (revisione 106999)
+++ src/zope/testing/testrunner/formatter.py (copia locale)
@@ -19,10 +19,9 @@
import sys
import re
import traceback
+import warnings
-from zope.testing import doctest
-
doctest_template = """
File "%s", line %s, in %s
@@ -328,6 +327,9 @@
def format_traceback(self, exc_info):
"""Format the traceback."""
v = exc_info[1]
+warnings.simplefilter('ignore')
+from zope.testing import doctest
+warnings.filters.pop()
if isinstance(v, doctest.DocTestFailureException):
tb = v.args[0]
elif isinstance(v, doctest.DocTestFailure):
@@ -560,6 +562,9 @@
print
print self.colorize('error', msg)
v = exc_info[1]
+warnings.simplefilter('ignore');
+from zope.testing import doctest
+warnings.filters.pop()
if isinstance(v, doctest.DocTestFailureException):
self.print_doctest_failure(v.args[0])
elif isinstance(v, doctest.DocTestFailure):
Index: src/zope/testing/testrunner/doctest.py
===
--- src/zope/testing/testrunner/doctest.py (revisione 106999)
+++ src/zope/testing/testrunner/doctest.py (copia locale)
@@ -17,10 +17,11 @@
"""
import sys
-from zope.testing import doctest
import zope.testing.testrunner.feature
+from zope.testing import doctest
+
class DocTest(zope.testing.testrunner.feature.Feature):
active = True
Index: src/zope/testing/testrunner/runner.py
===
--- src/zope/testing/testrunner/runner.py (revisione 106999)
+++ src/zope/testing/testrunner/runner.py (copia locale)
@@ -34,7 +34,6 @@
from zope.testing.testrunner.refcount import TrackRefs
from zope.testing.testrunner.options import get_options
import zope.testing.testrunner.coverage
-import zope.testing.testrunner.doctest
import zope.testing.testrunner.logsupport
import zope.testing.testrunner.selftest
import zope.testing.testrunner.profiling
@@ -177,7 +176,10 @@
self.features.append(zope.testing.testrunner.selftest.SelfTest(self))
self.features.append(zope.testing.testrunner.logsupport.Logging(self))
self.features.append(zope.testing.testrunner.coverage.Coverage(self))
-self.features.append(zope.testing.testrunner.doctest.DocTest(self))
+if options.ndiff or options.udiff or options.cdiff or \
+ options.report_only_first_failure is not None:
+from zope.testing.testrunner.doctest import DocTest
+self.features.append(DocTest(self))
self.features.append(zope.testing.testrunner.profiling.Profiling(self))
if is_jython:
# Jython GC support is not yet implemented
Index: src/zope/testing/testrunner/debug.py
===
--- src/zope/testing/testrunner/debug.py (revisione 106999)
+++ src/zope/testing/testrunner/debug.py (copia locale)
@@ -20,12 +20,12 @@
import sys
import pdb
-from zope.testing import doctest
import zope.testing.testrunner.interfaces
def post_mortem(exc_info):
err = exc_info[1]
+from zope.testing import doctest
if isinstance(err, (doctest.UnexpectedException, doctest.DocTest
Re: [Zope-dev] New release of zope.interface
* 2009-12-22 22:54, Hanno Schlichting wrote: > I'd rather see a new zope.testing release fixing the BBB foul, which is > much less hassle. Isn't the new release emitting a deprecation warning? In this case, I'd fix zope.interface (and all the other packages). > zope.interface has C extensions and thus a new release needs all the > Windows binary eggs to be made again. Not a big issue, I can prepare all the Window eggs if this is thee problem; by the way, i checked out your releases (zope.schema, zope.location, zope.configuration) and the source package is released as a zip file: is there a policy for using tarballs for ZTK packages or it is okey to use zip files, too? Thanks, 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 )
[Zope-dev] New release of zope.interface
I fixed the unit tests of the zope.interface package, which were broken by the last release of zope.testing. Can somebody make a release, or give me access to the PyPI package? My nickname is kobold. Best regards. 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 )
[Zope-dev] Removing dependency between zope.location and zope.copy
Hello,
I'm wondering if it would be possible to drop the dependency between
zope.location and zope.copy. It makes sense to me because zope.location
depends on zope.copy only because it registers a LocationCopyHook, not
because it is really using anything from that package.
Attached to this message you can find my (proposed) patch to remove the
dependency making the adapter registration optional, and informing the
developer that zope.copy is needed is he is importing directly the
zope.location.pickling module.
Comments?
Thanks,
Fabio
Index: buildout.cfg
===
--- buildout.cfg (revisione 106858)
+++ buildout.cfg (copia locale)
@@ -4,11 +4,11 @@
[test]
recipe = zc.recipe.testrunner
-eggs = zope.location
+eggs = zope.location [test]
[coverage-test]
recipe = zc.recipe.testrunner
-eggs = zope.location
+eggs = zope.location [test]
defaults = ['--coverage', '../../coverage']
[coverage-report]
Index: src/zope/location/configure.zcml
===
--- src/zope/location/configure.zcml (revisione 106858)
+++ src/zope/location/configure.zcml (copia locale)
@@ -1,7 +1,9 @@
-http://namespaces.zope.org/zope";>
+http://namespaces.zope.org/zope";
+ zcml:xmlns="http://namespaces.zope.org/zcml";>
-
+
Index: src/zope/location/pickling.py
===
--- src/zope/location/pickling.py (revisione 106858)
+++ src/zope/location/pickling.py (copia locale)
@@ -18,13 +18,17 @@
__docformat__ = 'restructuredtext'
from zope.component import adapts
-from zope.copy.interfaces import ICopyHook, ResumeCopy
from zope.interface import implements
-
from zope.location.interfaces import ILocation
from zope.location.location import inside
+try:
+from zope.copy.interfaces import ICopyHook, ResumeCopy
+except ImportError:
+raise NotImplementedError("zope.location.pickling is not supported "
+"because zope.copy is not available")
+
class LocationCopyHook(object):
"""Copy hook to preserve copying referenced objects that are not
located inside object that's being copied.
Index: setup.py
===
--- setup.py (revisione 106858)
+++ setup.py (copia locale)
@@ -56,13 +56,14 @@
packages=find_packages('src'),
package_dir = {'': 'src'},
namespace_packages=['zope',],
+ tests_require=['zope.copy'],
install_requires=['setuptools',
'zope.interface',
'zope.schema>=3.5.1dev',
'zope.component>=3.8.0',
'zope.proxy>3.3',
-'zope.copy',
],
+ extras_require=dict(test=['zope.copy']),
include_package_data = True,
zip_safe = False,
)
___
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] New release needed for z3c.recipe.depgraph
Hello, I've just committed a simple patch to allow extras in the eggs option of a z3c.recipe.depgraph-based recipe. While doing it, I just realized that the 0.4 release has not been uploaded to PyPI, where the most recent version is 0.3. Package index owners for the package are hannosch, faassen. Can you please release 0.4 (or better, 0.5 with my fix) to PyPI? My PyPI nickname is kobold, in case you want me to prepare the release. Thanks, 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] improving the utility and adapter lookup APIs
* 2009-11-25 19:35, Tres Seaver wrote: > >> IFoo() > >> IFoo(x) > >> IFoo(x, y) > > You can't use an arbitrary number of positional arguments for the > contexts, because we need to support the named / default cases too. I'm probably saying something very stupid... What's wrong with the it? Can't we define something like: def __call__(self, *args, **kw): to get a multi adapter in this way? IFoo(x, y, default=None, name='something') Best regards, 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] Merging the zope.component's conditional support for zope.security
Hello, * 2009-11-16 10:25, Martijn Faassen wrote: > > Anyone willing to make a new release of zope.component and zope.sendmmail, > > or give me the pypi access to do it? > What's your pypi username? kobold Thanks, 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] Merging the zope.component's conditional support for zope.security
Anyone willing to make a new release of zope.component and zope.sendmmail, or give me the pypi access to do it? Thanks, Fabio * 2009-11-08 13:35, Fabio Tranchitella wrote: > * 2009-11-06 20:34, Fabio Tranchitella wrote: > > I'm going to merge the code on Sunday, if nobody objects. > > I merged the branch back to zope.component and fixed zope.sendmail, which > was importing a security-related symbol from zope.component.zcml; I ran the > ZTK tests and I have no failures. > > The only missing thing is to release the new versions of zope.component and > zope.sendmail and (maybe) update the ZTK KGS. I don't have the permissions > to do the release, though. ___ 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] Merging the zope.component's conditional support for zope.security
Hello, * 2009-11-06 20:34, Fabio Tranchitella wrote: > I'm going to merge the code on Sunday, if nobody objects. I merged the branch back to zope.component and fixed zope.sendmail, which was importing a security-related symbol from zope.component.zcml; I ran the ZTK tests and I have no failures. The only missing thing is to release the new versions of zope.component and zope.sendmail and (maybe) update the ZTK KGS. I don't have the permissions to do the release, though. Best regards. 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.site.hooks
Hey Thomas, * 2009-10-19 10:12, Thomas Lotze wrote: > I'd like to tackle the move of zope.site.hooks to zope.component this > week. While I'm sure that that wouldn't conflict with your work, I would > prefer releasing both refactorings at once as they both involve using the > new scheme of conditional zope.security imports. Do you suppose you could > get your branch finished and merged this week? If not, I'd be willing to > help you with it. Yes, I think I can make it; I will work on this from tomorrow. We can coordinate on IRC (my nick is kobold). Thanks, 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.site.hooks
* 2009-10-14 17:33, Martijn Faassen wrote: > That's more or less what I have in mind. The suggestions are just about > trying to make it prettier. > ... > [snip] I applied your suggestions, and I think now the code is more robust; with this branch, all the ZTK tests pass except zope.sendmail, which can be easily fixed (it is importing PermissionPublic from zope.component.zcml, which is a bad idea by itself). > I think we need to try to separate security-related tests from the rest > of the tests, and test that they fail with the right errors if > zope.security is not present and do the right thing when it is. > > It would also be nice to be able to run the other tests with or without > zope.security - the result should be identical. Did you check the ConditionalImports test layer in my zope.component branch? It is already running the tests with and without zope.security. I want to bring the test coverage for zope.component.zcml and zope.component.security to 100% before asking to merge it back to the trunk. Any other suggestion? Thanks, 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.site.hooks
* 2009-10-12 08:55, Wichert Akkerman wrote: > Perhaps it is an idea to make zope.component an extension for > repoze.zcml? repoze.zcml already exists and works well, and people who > want the extra zope magic can keep using zope.component. I suspect that > is less work than trying to split up zope.component. repoze.zcml uses a different ZCML namespace (bfg), so you cannot replace zope.component.zcml with repoze.zcml without changing your code. 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.site.hooks
Hello, * 2009-10-09 15:37, Martijn Faassen wrote: > I'm okay with *not* doing the split up and going with your idea, but I > think eventually such a split up would simplify things. One advantage > would be that someone could examine repoze.zcml and not see distracting > ZCML implementations in zope.component *too*. I may be wrong, but I suppose the dependency on zope.security in zope.component is the only reason why repoze.zcml is around. I tried to implement my idea here: svn://svn.zope.org/repos/main/zope.component/branches/conditional-zope.security This is a quite intrusive change, so please take it as a "suggestion" and not as a real proposal: is this the right approach? I did not (yet) write all the tests needed (and I don't like the idea of duplicating the tests in zcml_conditional.txt, to be honest). Thanks, 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.site.hooks
* 2009-10-09 13:59, Martijn Faassen wrote: > I propose we create a new zope.componentzcml package that contains the > zope.component.zcml code. This package is *optionally* dependent on > zope.security as well as zope.proxy. It should work with just a > dependency on zope.i18nmessageid and zope.configuration. We should figure > out a way to test out both situations somehow. Ideas? zope.component's dependencies are: install_requires=['setuptools', 'zope.interface', 'zope.event', ], The extra dependencies are: extras_require = dict( hook = ['zope.hookable'], persistentregistry = ['ZODB3'], zcml = ['zope.configuration', 'zope.security', 'zope.proxy', 'zope.i18nmessageid', ], test = ['ZODB3', 'zope.testing', 'zope.hookable', 'zope.location', ], docs = ['z3c.recipe.sphinxdoc'], ), Considering that we are not really getting rid of all the extras, instead of creating a new package I'd rather make the dependency on zope.security and zope.proxy optional in zope.component: it is possible to do it with conditional imports, and we are not breaking any application already depending on zope.component[zcml], unless they need zope.security but they are not directly depending on it (which is bad and wrong, in any case). Note that we are already using conditional imports in zope.component._api. Anyway, I'm fine with what Martijn proposed if nobody else supports my idea. Best regards, 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.site.hooks
* 2009-10-07 22:40, Martijn Faassen wrote: > I think it would be interesting to review zope.component.zcml and see how > it depends on security, and see whether we cannot make the dependency > optional too. I fully agree with this, and the main reason why I use a package like repoze.zcml is to get rid of the (unnecessary) dependency on zope.security. The only problem with making the dependency on zope.security optional is related to the "permission" attribute in the zope.component ZCML directives, which is a zope.security.zcml.Permission. All the proxying stuff can be made optional with conditional imports. I think the only solution to make zope.security optional without removing the "permission" attribute is to do something like: try: from zope.security.zcml import Permission except ImportError: from zope.schema import TextLine as Permission Do anybody else has better ideas? Thanks, 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.filerepresentation release
Hello, * 2009-10-05 12:15, Martin Aspeli wrote: > Would anyone mind making a 3.5.1 release, or else give me PyPI rights so > that I can do it myself. Shouldn't this be 3.6.0? Best regards, 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] ploneconf2009
* 2009-09-30 18:04, Adam GROSZER wrote: > And ZTK sprinting? I'm not going to the Plone conference (at least officially), but I'd be interested in the ZTK sprinting. Anyone joining us? :) 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.location.pickling.PathPersistent and BBB
Hello, * 2009-09-16 15:34, Thomas Lotze wrote: > There's a PathPersistent class in zope.location.pickling which is > decorated with a recent BBB comment, and had been questioned by a XXX > comment for some time before that. > > [snip] > > Does anyone object to these changes? +1, I fully agree with the change. 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] Deprecated code in zope.location
Hello, * 2009-08-21 21:15, Dan Korostelev wrote: > > What about removing the use of zope.deferredimport from zope.location and > > make a new major release of zope.location? > > +1, just change that to plain imports with # BBB comments. Would it also be possible to remove the dependency of zope.location on zope.copy? It is only needed to register an adapter for ICopyHook, which can be made optional in the ZCML. To me it looks a wise choice, because zope.location is well usable without zope.copy, and if somebody needs the hook it is because he will be using zope.copy, so he must depend on it. I prepared these changes in a branch, can somebody review them? svn://svn.zope.org/repos/main/zope.location/branches/optional-zope.copy Thanks, Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: zope.app.publisher refactoring
* 2009-08-21 21:07, Dan Korostelev wrote: > IXMLRPCPublisher adapters for zope.container - move them to > zope.container. The IBrowserPublisher adapters that are already there, so > it won't make things worser. The zope.container package may be refactored > later to break dependency on zope.publisher though. -1, I think this is bad and we shouldn't do it: zope.container has nothing to do with the publisher, and it shouldn't depend on it. The fact that we already have the adapters for IBrowserPublisher shouldn't be a reason to bring more publisher-related stuff over there. Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Deprecated code in zope.location
Hello, we deprecated locationCopy and CopyPersistent from zope.locaton.pickling with the 3.5.3 release (which should have been a new major release, by the way). This introduced a new dependency on zope.deferredimport, but I just realized that according to the decisions taken by the streering group, the right way to deprecate code is to *not* use zope.deferredimport: http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html I thus propose to stop using zope.deferredimport in core ZTK packages, as stated in the page I mentioned above, unless a new decision is made by who is in charge of making decisions. What about removing the use of zope.deferredimport from zope.location and make a new major release of zope.location? Thanks, Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZTK with no test failures on Python 2.4, 2.5 and 2.6!
Hello, with the today's changes, the KGS for the Zope Toolkit[1] has no build failures on Python 2.4, 2.5 and 2.6 for both 32bit and 64bit Linux. Kudos to everybody to work to achieve this result! The next steps are: - Add Windows and MacOS build slaves; - Move the kgs definition to a better place than a branch (see [1]). Anyone interested in helping out running build slaves for Windows and MacOS? Running the tests require between 5 and 15 minutes of computation each day (depending on your hardware) and we can arrange the best time to run them for your particular build slave. The only requirement is having Python 2.4, 2.5 and 2.6 installed, better if with a virtualenv environment. If you are interested, please get in touch with me and I will provide you the configuration details. Fabio [1] svn+ssh://svn.zope.org/repos/main/zopetoolkit/branches/jim-kgs/kgs ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New release of zope.app.testing fixes tests on Python 2.4
Hello, * 2009-08-20 15:04, Michael Howitz wrote: > I gave the user 'kobold' (hoping that is you) the owner role on > zope.app.testing. Thanks, I've just made the release. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZTK: upgrade zope.index from 3.5.2 to 3.6.0
Hello, zope.index 3.5.2 (which is part of the ZTK set) has failing tests on all the supported python versions (2.4, 2.5 and 2.6) on 64 bit platforms. These test failures have been fixed by the 3.6.0 release. I propose to upgrade zope.index from 3.5.2 to 3.6.0 in the KGS; I already ran the ZTK compat tests with this change on Python 2.5 and 2.6 (64 bits) and I have no regressions. After the change I'll also check the buildbot outputs to see if nothing breaks on 32 bits platforms and on Python 2.4. Thanks, Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] New release of zope.app.testing fixes tests on Python 2.4
Hello, zope.app.testing (which is part of thee ZTK) has failing tests on Python 2.4 introduced by the release 3.7.1 on the 2009-07-21 ; I've just committed the fix (two lines diff), and I would like to make a new release and update the ZTK KGS. I don't have the right to make a new release on PyPi, can somebody help me please? Thanks, Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to update the ZTK KGS (was Re: Working KGS tool! (was Re: IRC discussion about testing))
Hello, * 2009-08-18 14:57, Jan-Jaap Driessen wrote: > I would like to volunteer OSX buildbot slaves, buildbot master if necessary. I'm currently running a buildbot master with two salves (linux 32bit and 64bit): http://buildbot.tranchitella.it/ztk/ It is running the tests in the trunk for all the packages in the ZTK (as defined by Jim) as well as the ZTK KGS tests with compattest. Will we have an "official" buildbot instance somewhere under the zope.org domain? In this case, I'm willing to administer and maintain it, if nobody else steps in. Best regards, Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: z3c.bobopublisher
Hello, * 2009-08-17 18:27, Jim Fulton wrote: > You should also look at the nascent bozo projects, especially bozo.reuse. Looking at the documentation it looks wonderful stuff! Looking forward to seeing it. :) Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RFC: z3c.bobopublisher
Hello, After messing up with my old-style Zope3 applications and getting crazy understanding the interactions between zope.publisher, zope.app.publisher and zope.app.publication, I decided to try bobo, the lightweight framework Jim published a couple of months ago. It worked out very well new projects, but our applications (and thus our programming patterns) are heavily based on zope.publisher and friends, so I came up with the idea of reimplementing the zope publisher and the zope publication frameworks using bobo. z3c.bobopublisher is a minimalistic replacement for zope.publisher, zope.app.publisher, zope.app.publication and zope.traversing; we are using it together with repoze.tm2 (to map transactions to requests) in a WSGI pipeline. What do you think about it? I'd be curious to know your opinion, if you like the idea and if you have suggestions and/or critics. Best regards, Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] chameleon.core removes the meta http-equiv="content-type" tag
Hello,
I hope this is the right mailing list for such a question. Why does
chameleon.core removes the meta tag http-equiv="content-type" from the
output?
In template.py, line 286:
# Look for an encoding specification in the meta tag
match = utils.re_meta.search(body)
if match is not None:
content_type, encoding = match.groups()
# TODO: Shouldn't / stripping
# be in PageTemplate.__call__()?
body = utils.re_meta.sub("", body)
else:
content_type = None
encoding = config.DEFAULT_ENCODING
I couldn't find the explanation anywhere in the source code nor in the
documentation.
Thanks,
Fabio
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Working KGS tool! (was Re: IRC discussion about testing)
Hello, * 2009-08-13 13:06, Jim Fulton wrote: > So, I think we now have a tool that will let us take the next steps. Can > we all agree on this? Yey, great! I will update my buildbot instance to use this system. Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.publisher/trunk/ Moved dependency on zope.testing from install_requires to tests_require.
Hello, * 2009-08-08 16:20, Hanno Schlichting wrote: > On Sat, Aug 8, 2009 at 2:33 PM, Fabio Tranchitella wrote: > > Log message for revision 102578: > > Moved dependency on zope.testing from install_requires to tests_require. > > I thought we were not using tests_require yet, as it doesn't work with > zope.testing / buildout properly. Instead we use extra requires named > test for this purpose. In zope.component we use tests_require, in the very same way, for example. Shall I remove it there, too? Is there a policy/document which explains how we use extras and tests_require? > I'm a bit hesitant to introduce a test extra if it is just for > zope.testing, though. The complication introduced by the extra doesn't > seem to outweigh the advantage of loosing that one package to me. To me it looks weird: tests_extra is there for this specific reason. Why shouldn't we use it? Thanks. Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KGS trunk without failures
Hello Jim, * 2009-08-07 12:28, Jim Fulton wrote: > How to do you specify the projects to be tested? Does every project in > versions get tested? If so, how do you specify versions for projects that > you don't want to run tests for but do want to fix the version of. In my recipe, it automatically tests all the libraries that are marked as tested=true in the controlled-packages.cfg, but you can filter and test only a subset of those packages, for example: [test-kgs] recipe = z3c.recipe.kgs kgs = http://svn.zope.org/*checkout*/zope.release/trunk/releases/controlled-packages.cfg packages = zope.component zope.interface zope.event zope.configuration If somebody tells me how it is possible to get "projects" from the controlled-packages.cfg using zope.kgs, I can modify the recipe code to understand it. :) -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KGS trunk without failures
Hello Wolfgang, * 2009-08-07 11:42, Wolfgang Schnerring wrote: > [buildout] > develop = . > parts = compat > extends = http://url/to/kgs/versions.cfg > # assuming said versions.cfg uses a section called [versions]: > versions = versions I've done something similar in z3c.recipe.kgs (which is a fork of compattest, I did not want to commit anything there, but I'm more than happy to bring back my changes). The KGS is defined here: http://svn.zope.org/*checkout*/zope.release/trunk/releases/controlled-packages.cfg IMHO the KGS testing should be done using the controlled-packages.cfg and not versions, because some of the packages in the KGS are marked as not to be tested. > Regarding the KGS, I have a question: Where is the current KGS and how > do we update it? > By "where is" I mean the location of the versions.cfg, AFAICK, It can be built from zope.release. > and by "update" I mean that I'd like this operation to involve no manual > interaction other than committing the new version number to SVN. I suppose there is no policy (yet) regarding how we manage the KGS. Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZTK policy and package list (was Re: List of packages in the ZTK)
I've created a policy draft as well as an initial list of packages on a wiki page, which I hope will help us to collaborate on the list: http://wiki.zope.org/zope3/ZTK I've put into the list the packages that I'd consider part of the ZTK and that I use in my applications. I don't know anything about grok and I doN't have a list of ZTK libraries used by zope2 or repoze. I'd like to ask help from everybody who cares about the ZTK to enhance the list adding the packages that they use, their zope.org username in the list of the developers for the package they are willing to maintain and the framework which are consumers of the libraries. IMHO, it is easier to get a real list if we start from an empty one and we add packages instead of starting from a huge list removing packages. Thanks, Fabio * 2009-08-06 23:56, Wichert Akkerman wrote: > > This sounds like the right starting point to me. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Simplifying dependencies of zope.app.publisher
Hello, * 2009-08-06 18:55, Martijn Faassen wrote: > > I was analyzing zope.app.publisher, and I found that it would be possible > > to remove its dependency on zope.container because the latter is only used > > in zope/app/publisher/xmlrpc/configure.zcml to declare thee views like > > this: > > > >> for="zope.container.interfaces.IItemContainer" > > type="zope.publisher.interfaces.xmlrpc.IXMLRPCRequest" > > provides="zope.publisher.interfaces.xmlrpc.IXMLRPCPublisher" > > factory="zope.container.traversal.ItemTraverser" > > permission="zope.Public" > > /> > > > > I think these snippets should me moved to zope.container's configure.zcml, > > where we already have other traversers. > > > > Do you agree with this change? > > I remember looking at this relationship in the past but I don't remember > noticing it was this easy. If this looks possible, by all means go ahead. I don't think this change would be correct; we have a weird situation, because: - zope.app.publisher depends on zope.container only because xmlrpc's configure.zcml defines a couple of traversers for some zope.container interfaces (providing zope.publisher.interfaces.xmlrpc.IXMLRPCPublisher); - zope.container by itself depends on zope.publisher, because it defines some traversers for some zope.container interfaces (providing zope.publisher.interfaces.browser.IBrowserRequest). It is weird because XMLRPC and Browserrequest are handled in different ways: the former is configured by zope.app.publisher, the latter by zope.container itself. Jim suggested that zope.container shouldn't assume that I want to use zope.publisher, and thus it is not a good idea to move the configuration of the XMLRPC traversers to zope.container. My knowledge of the zope.publisher is too limited to do any change in this area, but to me it looks like these configurations (both of them) should be perfomed by zope.app.publisher (removing the dependency zope.container -> zope.publisher), but conditionally (zcml:condition) only if zope.container is installed, (removing the dependency zope.app.publisher -> zope.container). Anyway, I'm not going to dig more into this problem until we clearly define the ZTK and the policies to manage it. :) Best regards. Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] List of packages in the ZTK
Hello, * 2009-08-06 19:30, Martijn Faassen wrote: > We need to get a procedure in place to do compat tests of what's in that > list, dependency graph guarding of what's in that list, and locking down > a KGS for that list. I think that since we have a list doing all these > things is only a matter of work - there's no fundamental questions we > need answered before we can do this work. Once the base is there we can > expand on it. I'm working to improve the KGS for the Zope Toolkit with automated testing and explicit policies. For example, I set up a buildbot instance here: http://buildbot.tranchitella.it/ztk/ For a subset of the KGS, it runs the tests for the current trunk as well as the tests for each of of the most recent released packages from the KGS. The idea is that we can be sure that the current trunk of a given package does not introduce test failures in any package in the KGS. The buildbot uses z3c.recipe.kgs (which is a mock-up you can download from svn.zope.org and not yet uploaded to pypi) and the KGS as defined here: http://svn.zope.org/*checkout*/zope.release/trunk/releases/controlled-packages.cfg Everything seems to work pretty well, and I'm down to three-four failures for my subset. > I think what we need is a policy for adding packages into this list, and > retiring packages from the list. Yep, this was my original question: I just need a list of packages to submit to my buildbot instance. :) I still think that starting from a very small list, allowing zope committers to add packages making an explicit commitment to maintain them would give us a better overview of what does "ZTK" mean for each of us. Best regards, Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] List of packages in the ZTK
Hello, * 2009-08-06 17:03, Tres Seaver wrote: > > How about another one: > > > > * the package has to be usable with all of Zope 2, grok and the Zope 3 > > application server > > > > That guarantees the stated goal that ZTK is reusable. > > I would restrict it to the "big toolkit" set which is "used by" those > three, rather than "usable with" them. Packages which aren't actually > used by those frameworks are objectively less well supported, even if > some developers use them for some apps built on top of the frameworks. Am I correct saying that your idea is to restrict the ZTK to the packages defined as the intersection of the dependencies of zope2, zope3 and grok? ZTK = intersection ( zope2-dependencies , zope3-dependencies, grok ) I don't think this definition fits our needs, but my skills on gron and zope2 are too limited to bring counterexamples. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] List of packages in the ZTK
* 2009-08-06 15:30, Wichert Akkerman wrote: > How about another one: > > * the package has to be usable with all of Zope 2, grok and the Zope 3 >application server Yep, I agree. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] List of packages in the ZTK
Hello, it is evident that there is no consensus on the list of packages that are part of the Zope Toolkit. As Gary suggested me, it looks like the concept of ZTK is different for each developer and it is more or less "the packages I use and I care about". We need a policy to define the ZTK in an explicit way, otherwise we will never get a *real* ZTK KGS that can be used to build applications and the whole concept of ZTK will always be fuzzy. Christian prepared a list of packages which is available here: http://docs.zope.org/zopetoolkit/about/packages.html I propose a (very) simple policy, which we can use to improve the current situation: * a package is part of the ZTK if the following criteria are met: - It has at least N zope developers (with commit rights) who explicitly expressed interest in maintaining the package (because they use it in their projects, for example); N > 1, at least; - All its dependencies (excluding testing dependencies) are part of the ZTK; * we have to ensure, using automated testing, that each package: - has no test failures; - does not introduce test failures in any of the other ZTK packages; * the ZTK KGS only includes the packages that are part of the ZTK; we will provide an extended KGS (which uses the ZTK KGS) with more packages if needed. I would like to add a new column to the table in the aforementioned page listing the developers who are interested in maintaining the package. Ideally, in a couple of weeks we will have a better overview of what does the ZTK mean to each of us. Ideas? Comments? -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Why does zope.tales explicitly pin versions in buildout.cfg?
* 2009-08-06 08:27, Shane Hathaway wrote: > Sure. Pinned versions are OK for a maintenance branch, but not the > trunk. Thanks, I just committed the change. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Why does zope.tales explicitly pin versions in buildout.cfg?
Hello, this is the buildout.cfg in zope.tales: [buildout] develop = . parts = test versions = versions [test] recipe = zc.recipe.testrunner eggs = zope.tales [versions] zope.traversing = 3.4.0 zope.app.publisher = 3.4. Is there a specific reason for having the version pinning? Automatic testing of zope.tales obviously fails using the KGS, because zope.traversing there is 3.7.1. Is it possible to remove the "versions" stanza? Thanks, Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Simplifying dependencies of zope.app.publisher
Hello, I'm sorry if I am flooding the list with all my requests/messages, but I don't want to introduce changes without approval of more experienced zope developers. I was analyzing zope.app.publisher, and I found that it would be possible to remove its dependency on zope.container because the latter is only used in zope/app/publisher/xmlrpc/configure.zcml to declare thee views like this: I think these snippets should me moved to zope.container's configure.zcml, where we already have other traversers. Do you agree with this change? -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Packages to be released
Hello, I'd like to release some packages with fixed/improved dependencies: - zope.location - zope.sendmail - zope.pagetemplate - zope.app.publisher - zope.filerepresentation These packages are already ok in the repository, but I don't have the rights to do the upload to pypi. Can somebody do the releases? Can I prepare the job in someway? Can I have release permissions for the packages? My pypi nickname is kobold. Thanks, Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Breaking the dep cycle between zope.{container, filerepresentation}
Hello, I just committed the removal of the dependency from zope.filerepresentation to zope.container, breaking the dependency cycle. * 2009-07-08 15:13, Jim Fulton wrote: > Sure, but if they want to *use* zope.container.directory, they have to > separately import zope.filerepresentation.interfaces, in which case > they're already depending on it, and a dependency in zope.container, > even in an extra, is superfluous. It seems the only user of zope.container.directory is zope.app.dav, but for this reason I'm not going to touch zope.container at all. All in all, remove the circular dependency was my original goal. :) Thanks. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Breaking the dep cycle between zope.{container, filerepresentation}
Hello, * 2009-07-08 12:51, Jim Fulton wrote: > I find it a bit hard to believe that there are no clients of these > interfaces, but, if that's the case, I suggest deprecating > zope.filerepresentation and zope.container.directory. In that case, I'd > just remove the dependency in zope.container on zope.filerepresentation. > If an application is going to use zope.container.directory, it will need > to import zope.filerepresentation.interfaces itself, and it will have the > zope.filerepresentation dependency itself. I'd add deprecation warning > in zope.container.directory. I wouldn't add these interfaces to > zope.container.interfaces. What about adding zope.filerepresentation as an extras_require "directory"? If somebody is using zope.container.directory, it is possible to depend on zope.container [directory]. Best regards. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Breaking the dep cycle between zope.{container, filerepresentation}
Hello, I would like to break the dep cycle between zope.container and zope.filerepresentation. I already prepared the two patches (attached to this e-mail), but I'm not confident enough with the zope3 repository to check in them without asking for comments. Is this the right way to break the dependency? I think nobody really uses zope.filerepresentation, so transforming it into a dummy package which just imports things from zope.container.interface is ok. Thanks in advance, Fabio Index: src/zope/filerepresentation/interfaces.py === --- src/zope/filerepresentation/interfaces.py (revisione 101720) +++ src/zope/filerepresentation/interfaces.py (copia locale) @@ -86,59 +86,7 @@ """ __docformat__ = 'restructuredtext' -from zope.interface import Interface -from zope.container.interfaces import IReadContainer, IWriteContainer +### BBB: these interfaces have been moved to zope.container.interfaces +from zope.container.interfaces import IReadFile, IWriteFile, IReadDirectory, \ +IWriteDirectory, IDirectoryFactory, IFileFactory -class IReadFile(Interface): -"""Provide read access to file data -""" - -def read(): -"""Return the file data -""" - -def size(): -"""Return the data length -""" - -class IWriteFile(Interface): - -def write(data): -"""Update the file data -""" - -# TODO: We will add ILargeReadFile and ILargeWriteFile to efficiently -# handle large data. - -class IReadDirectory(IReadContainer): -"""Objects that should be treated as directories for reading -""" - -class IWriteDirectory(IWriteContainer): -"""Objects that should be treated as directories for writing -""" - -class IDirectoryFactory(Interface): - -def __call__(name): -"""Create a directory - -where a directory is an object with adapters to IReadDirectory -and IWriteDirectory. - -""" - -class IFileFactory(Interface): - -def __call__(name, content_type, data): -"""Create a file - -where a file is an object with adapters to `IReadFile` -and `IWriteFile`. - -The file `name`, content `type`, and `data` are provided to help -create the object. -""" - -# TODO: we will add additional interfaces for WebDAV and File-system -# synchronization. Index: setup.py === --- setup.py (revisione 101720) +++ setup.py (copia locale) @@ -51,8 +51,7 @@ test=['zope.testing', ]), install_requires=['setuptools', -'zope.interface', -'zope.container' +'zope.container >= 3.8.3' ], include_package_data=True, zip_safe=True, Index: CHANGES.txt === --- CHANGES.txt (revisione 101720) +++ CHANGES.txt (copia locale) @@ -5,8 +5,10 @@ 3.8.3 (unreleased) -- -- ... +- Moved interfaces from zope.filerepresentation to zope.container.interfaces. +- Removed dependency on zope.filerepresentation. + 3.8.2 (2009-05-17) -- Index: src/zope/container/configure.zcml === --- src/zope/container/configure.zcml (revisione 101720) +++ src/zope/container/configure.zcml (copia locale) @@ -13,26 +13,26 @@ Index: src/zope/container/directory.py === --- src/zope/container/directory.py (revisione 101720) +++ src/zope/container/directory.py (copia locale) @@ -27,9 +27,9 @@ from zope.interface import implements +from zope.container.interfaces import IDirectoryFactory from zope.location.interfaces import ISite from zope.security.proxy import removeSecurityProxy -import zope.filerepresentation.interfaces MARKER = object() @@ -49,7 +49,7 @@ of the same class as it's context. """ -implements(zope.filerepresentation.interfaces.IDirectoryFactory) +implements(IDirectoryFactory) def __init__(self, context): self.context = context Index: src/zope/container/interfaces.py === --- src/zope/container/interfaces.py (revisione 101720) +++ src/zope/container/interfaces.py (copia locale) @@ -291,3 +291,129 @@ def matches(id): """Return True if the id matches the filter criteria.""" + + +## +# File-system representation interfaces +# +# The interfaces defined here are used for file-system and +# file-system-like representations of objects, such as file-system +# synchronization, FTP, PUT, and WebDAV. +# +# There are three issues we need to deal with: +# +# File system representation +# +# Every object is either a dir
Re: [Zope-dev] A couple of questions about (maybe) missing dependencies
Hello, * 2009-06-29 10:25, Martijn Faassen wrote: > Seems like a bug at first glance. Feel free to add the dependency back > (though I hope we can look into removing it again). I would love to, but I don't have (yet) commit rights on svn.zope.org. :) Thanks, Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] A couple of questions about (maybe) missing dependencies
Hello, While analyzing the dependency graph of one of our applications, I found some missing dependencies. I'm not sure these are bugs, but I'd like to ask your opinion about them: - zope.app.publisher does not depend anymore on zope.app.pagetemplate, but it uses it in src/zope/app/publisher/browser/viewmeta.py >>> zope.app.pagetemplate.simpleviewclass import SimpleViewClass - shouldn't zope.pagetemplate depend on zope.security [untrustedpython]? it imports it in engine.py: >>> from zope.security.untrustedpython import rcompile - I think we should release zope.location (added miss dependency on zope.deferredimport, it is ok in trunk but not yet released); - I think we should release zope.sendmail (not it depends on transaction instead of ZODB3, it is ok in trunk but not yet released). Thanks. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.sendmail dependencies
Hello, it looks like zope.sendmail should depend on transaction (because that's what it is using, importing it) and not on the full ZODB3. Am I missing something? Thanks, Fabio ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] 2.5/2.6 support in Zope (Re: The future of Zope{2, 3} and Plone in Debian and Ubuntu)
* 2009-06-24 12:26, Jim Fulton wrote: > So then, how soon would 2.12 need to be released for you to not drop > debian support for Zope 2 and Plone? The problem is not Zope by itself but Plone, which still needs Zope 2.10, which in turn requires python 2.4. It seems that a new major release of Plone will happen at the end of the year, which is already too late for Ubuntu Karmic (next stable release). -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] 2.5/2.6 support in Zope (Re: The future of Zope{2, 3} and Plone in Debian and Ubuntu)
* 2009-06-24 11:39, Jim Fulton wrote: > >> The main problem for Zope2 is that the current stable upstream branch > >> (2.12) still requires python2.4. My fault, I meant 2.11 (which is the current stable). -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] The future of Zope{2, 3} and Plone in Debian and Ubuntu
Hello, * 2009-06-24 07:30, Balazs Ree wrote: > What's the reason for the removal of python2.4? Is there a technological > reason, or is this a policy decision? Don't forget that Plone users, who > are also the biggest consumer group of Zope / ZTK, still will be users of > 2.4 for a while. The unified installer is not the only installation > method used for Plone, in fact many users and the majority of deployments > use python + buildout. These users will need to read documentation and do > installation to be able to bootstrap their buildout, which is not exactly > a reason for them to choose Debian / Ubuntu in this case. We already have python2.5 and python2.6; after the release of stable (either Debian or Ubuntu), we have to provide security support for all the packages, and supporting three different versions of python is too much work. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Site -> Locus
* 2009-05-28 13:09, Martijn Faassen wrote: > What do people think about: > * the idea of renaming Site to Locus What is the technical advantage of renaming Site to Locus? To me it looks just like a (not so necessary) cosmetic change. Fabio. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] People in the "Zope 3" and "ZMI" teams
Hello there, * 2009-04-16 09:44, Martijn Faassen wrote: > Just so we don't lose track of who are interested in maintaining Zope 3 > (and/or the ZMI). I've distilled the following list of people who are > interested in helping maintain Zope 3. This might mean making sure > existing apps work, maintaining or replacing the ZMI, and working on > making sure installation works. We can work out these details over time. I've just checked out that the domain zope3.org is not owned by the Zope Corporation. Do you have any idea about it? Would it be possible to claim it back? I'm thinking about taking over maintenance of zope3 in the wider term (not only maintaining the code, but also the community around it). To be honest, zope3 (as it is today) is a nice platform for me and for my company to build web applications (and, in general, the ZCA is a nice platform for building not-only-web applications), and it would be a shame to loose it. To make explicit: I am not talking just about maintaining the ZMI, I'm talking about making zope3 a *real* user-friendly web framework, as (for example) grok is already right now. Thanks. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain the Zope 3 ZMI?
Hello, * 2009-04-14 19:35, Martijn Faassen wrote: > It might be an easier way to maintain this concept is to write a simple > UI for Zope 3 that only cares about installation of applications? It'd be > much less involved than all the ZMI code we currently have to worry > about. I'd be curious to know if anybody else is using ZMI for anything other than this; if this is the typical usage scenario, than reducing it to a simple UI is a good idea. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
Hello, * 2009-04-14 19:25, Martijn Faassen wrote: > Do you use the Zope 3 ZMI a lot? It depends on your meaning of "a lot": we do not use it as main UI, not even for the back-end, nevertheless we often use it for managing our "applications". I mean, adding/renaming/moving/editing objects to the ZODB, as well as configuring local components. I am sure that we are using only a small subset of the features ZMI offers right now, but I suppose we are not the only one, and I really think that maintaining and supporting it is important for the community. Best regards. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain the Zope 3 ZMI?
Hello there, * 2009-04-14 18:35, Martijn Faassen wrote: > So, who finds the Zope 3 ZMI useful? What parts of it do you find useful? > Are you interested in helping maintain it? We use the ZMI to manage applications, where applications are instances of a content object stored in the ZODB. All in all, we manage applications in a similar way we manage plone sites in zope2.x. If this specific feature is going to be removed, I'm willing to support and maintain it. Best regards. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] who wants to maintain Zope 3?
Hello, * 2009-04-13 12:50, Hermann Himmelbauer wrote: > > +1, to declaring Zope 3 dead. That should allow us to refactor the > > remaining packages much more aggressively and reduce the dependencies. > > -1 from my standpoint. Two of my projects are fully based on the Zope 3 > server, and switching to something else would be quite some pain. I fully agree: our company is based on zope3 technology, and we have at least three big deployments based on zope3 (yes, the application server) using ZODB and PostgreSQL/storm. I do not know in the details what would it mean to switch to the zope toolkit/repoze/whatever is fashionable today, but I suppose it would be quite painful for us. If the question was "who is interested in zope3, the application server, and willing to maintain it", I'd answer "me". Best regards. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
