[Zope-dev] svn.zope.org issue
Hi! Where can I report problems with svn.zope.org? For some days now I have trouble making checkins. Commits are successful, but somewhere in the post commit hook things go wrong. No mail is send to the checkins list and my svn client freezes - I guess because the server doesn't signal the commit is finished. Other people seem to have the same issue, the last checkin mail to the list was sent 2013-09-17. Cheers, Yuppie ___ 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] SVN: Zope/branches/2.12/ LP #1047318: Tighten import restrictions for restricted code.
Hi! Hano Schlichting wrote: Log message for revision 127792: LP #1047318: Tighten import restrictions for restricted code. CMF uses some ZTUtils in restricted code: Batch, LazyFilter, make_query and SimpleTreeMaker. The new Zope 2 releases (2.12.24 and 2.13.17) are not compatible with existing CMF releases. Is this intended? CMF could declare the ZTUtils it uses as public. But that would require new CMF releases for the new maintenance releases of Zope. And other packages might have the same problem. Where should this be fixed? Were the restrictions tightened too much in Zope? Cheers, Yuppie ___ 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 trunk: browser views
Hanno Schlichting wrote: On Tue, Jul 10, 2012 at 7:29 AM, yuppie y.2...@wcm-solutions.de wrote: Zope 2 has customized implementations of the ``browser:view`` and ``browser:page`` directives. I tried to make that code more similar to zope.browserpage without breaking Zope 2 and CMF. I guess the biggest change I made was removing the Five version of BrowserView from the base classes. Please let me know if you have any questions or if I did break something. Did you add a changelog entry? Maybe that could mention that the aq_* attributes are no longer available on those views/pages (Five's BrowserView's only purpose is to provide those for backwards compatibility). Done. Cheers, Yuppie ___ 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 trunk: browser views
Hi! Zope 2 has customized implementations of the ``browser:view`` and ``browser:page`` directives. I tried to make that code more similar to zope.browserpage without breaking Zope 2 and CMF. I guess the biggest change I made was removing the Five version of BrowserView from the base classes. Please let me know if you have any questions or if I did break something. Cheers, Yuppie ___ 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 trunk: browser views
Charlie Clark wrote: Am 10.07.2012, 16:29 Uhr, schrieb yuppie y.2...@wcm-solutions.de: I guess the biggest change I made was removing the Five version of BrowserView from the base classes. Please let me know if you have any questions or if I did break something. I'm sure that's going to break any code that has from Products.Five import BrowserView in it. What should this be replaced by? And what changes in ZCML? Most of my code sits upon CMF so I hope I should be reasonably insulated through that. But the change is probably a good thing™ so thanks in advance. What I wanted to say is that I removed that BrowserView from the classes automatically added by ``browser:view`` and ``browser:page`` directives. You still can import and use the Five version of BrowserView in classes specified explicitly in ZCML. Cheers, Yuppie ___ 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-tests - FAILED: 5, OK: 41, UNKNOWN: 1
Wolfgang Schnerring wrote: Thus, I'm really confused why the builder for ZTK 1.0 is picking this up, I've only bumped the version of zope.publisher in toolkit/trunk, nowhere else. Can somebody enlighten me what ZTK 1.0dev actually builds? See the [sources] section including comment: http://svn.zope.org/zopetoolkit/branches/1.0/ztk.cfg?rev=123141view=auto Cheers, Yuppie ___ 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 4 publisher/traversal, sprint topic
Hi! Leonardo Rochael Almeida wrote: After the last two rather serious security issues that were recently patched in the Zope2 code base, it is increasingly clear to me that, differently than what Hanno reported some time ago, it's not so much the ZMI that represents a huge security liability in the Zope codebase, but it's actually the way the current publisher happily traverses any attribute and publishes any method with docstring by default. Is that the fault of the publisher? AFAICT the biggest security problem of Zope2 is this line in OFS.SimpleItem.Item: # Allow (reluctantly) access to unprotected attributes __allow_access_to_unprotected_subobjects__=1 I'm not familiar with the details of the first hotfix, but the second one wouldn't have been necessary without that line. I propose to remove that line in Zope 4 and to add explicit security declarations where ever needed. The first part is easy, the second part a lot of work for many people. Cheers, Yuppie ___ 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] Hotfix for security vulnerability
Laurence Rowe wrote: This hotfix addresses a serious vulnerability in the Zope2 application server. Affected versions of Zope2 include: - - 2.12.x= 2.12.20 - - 2.13.x= 2.13.6 Older releases (2.11.x, 2.10.x, etc.) are not vulnerable. Can you confirm whether or not Zope 2.13.6 through 2.13.10 are affected? They are affected. 2.13.6 seems to be a typo. But AFAICT Plone is not affected because it doesn't use the default user folder implementation shipped with Zope. Cheers, Yuppie ___ 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] direction
Hi! Hanno Schlichting wrote: I think moving to Zope 2.12 and 2.13 does have some value for Nexedi or other large existing codebases, as you get support for current versions of the ZODB, Zope Toolkit packages and support for Python 2.7 with Zope 2.13. Since Python 2.7 is a long-term maintenance release for Python itself, this should provide a stable and good basis for the next years - the statements from the Python community aren't completely clear - but I'd expect to see ongoing maintenance until 2013 or maybe even 2015. With the big changes you propose for Zope 2, some existing projects/deployments will stay stuck with Zope 2.13 (or Zope 2.X if Zope trunk is not released as Zope 2.14). Long-term maintenance for Zope 2.13 would give these projects/deployments at least a few more years. Going forward I can see two paths for Zope 2. Either we don't touch it at all anymore and let it bitrot or we try to move it forward and adept it to current best practices of development. Since complete rewrites almost always fail, like we have seen with Zope 3 - I prefer changing Zope 2. +1 What I'm outlining here has of course almost nothing to do with the original idea and scope of Zope 2. Maybe at some point this should get a different name ;-) I don't want to discuss names, but I think the next release from Zope trunk should be explicitly a new *major* release. Cheers, Yuppie ___ 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-tests - FAILED: 17, OK: 91
Hi!
Marius Gedminas wrote:
On Wed, May 25, 2011 at 09:18:46AM -0400, Tres Seaver wrote:
[17] FAILED winbot / ztk_dev py_270_win64
https://mail.zope.org/pipermail/zope-tests/2011-May/041897.html
These are all the same bug::
-- $ -
Error in test testNoTargetLanguage
(zope.app.i18n.tests.test_translationdomain.TestTranslationDomain)
Traceback (most recent call last):
File c:\Python27_64\lib\unittest\case.py, line 318, in run
testMethod()
File
c:\buildslave\ztk_dev_py_270_win64\build\src\zope.i18n\src\zope\i18n\tests\test_itranslationdomain.py,
line 99, in testNoTargetLanguage
eq(translate('short_greeting', context=context, default=42), 42)
File
c:\buildslave\ztk_dev_py_270_win64\build\src\zope.app.i18n\src\zope\app\i18n\translationdomain.py,
line 74, in translate
catalog_names = self._catalogs.get(target_language, [])
TypeError: Object has default comparison
-- $ -
WTF? We have tests for zope.i18n which pull in code from zope.app.i18n?
Not only that, but we have an error being raised from the OOBTree
changes Jim landed in October, in a code base which hasn't changed since
March.
Buildout egg caches, maybe? Insufficient version pinning? newest = false
in a buildout.cfg? Who can tell?
I'm afraid I did break this: I added some sources for ZTK dependencies,
including ZODB/trunk.
This seems to be wrong in two ways:
1.) ZTK trunk obviously doesn't work with ZODB/trunk, it requires
ZODB/branches/3.10
I already changed this to make the tests pass again:
http://svn.zope.org/?rev=121808view=rev (Maybe ZTK trunk *should* work
with ZODB/trunk and that needs to be fixed instead?)
2.) maybe the ZTK should be tested with released versions of its
dependencies
My goal was to sync the list of sources with the list of versions and to
make it possible to extend ztk-sources.cfg in similar way as
ztk-versions.cfg. This way projects like Zope 2 don't have to maintain
redundant lists.
So instead of reverting my change I propose to make auto-checkout in
development.cfg an explicit list of all tested packages instead of using
a wildcard. Or to decide explicitly that we want to test the ZTK against
checkouts of its dependencies.
Any opinions?
Cheers,
Yuppie
___
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-tests - FAILED: 18, OK: 79, UNKNOWN: 1
Gediminas Paulauskas wrote: 2011/5/23 Tres Seavertsea...@palladion.com: [...] [19] FAILED winbot / ztk_dev py_270_win64 https://mail.zope.org/pipermail/zope-tests/2011-May/041695.html In each of these, he buildout fails (silently) while trying to check out code from SVN: mr.developer: svn: Can't create tunnel: The system cannot find the file specified. buildbot tries to checkout from svn+ssh, because sources were moved to separate files, ztk-sources.cfg and zopeapp-sources.cfg [1], and buildbot does not remove ssh+ from source urls in those files. [1] http://zope3.pov.lt/trac/changeset?new=121748%40zopetoolkit%2Ftrunkold=121746%40zopetoolkit%2Ftrunk Oops! My mistake. Hope this is fixed now: http://svn.zope.org/?rev=121787view=rev Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 2 PropertyManager: editing date properties
Hi!
AFAICS editing date properties is broken. But before I check in a fix,
I'd like to make sure the current behavior is not a feature.
The dual nature of DateTime objects marked as timezoneNaive is hard to
grasp: They are offset-naive *and* have a time zone. Only one of both
aspects can be respected in a specific situation. And there might be
different opinions which aspect is more important on the 'Properties'
tab of PropertyManager objects.
BTW: I think it was a mistake to add a timezoneNaive flag instead of
setting the timezone value of offset-naive DateTime objects to None.
This is the issue in the 'Properties' tab:
--
If you set a date property to '2011/03/09 11:00:00' and the machines
time zone is 'GMT+1', this kind of DateTime object is created:
dt = DateTime('2011/03/09 11:00:00')
dt.timezoneNaive()
True
dt.timezone()
'GMT+1'
dt.asdatetime()
datetime.datetime(2011, 3, 9, 11, 0)
After saving this DateTime object, '2011/03/09 11:00:00 GMT+1' is shown
on the 'Properties' tab. Note that our input didn't include a time zone
and the persistent object is marked as offset-naive. That's caused by
the __str__ method of DateTime:
str(dt)
'2011/03/09 11:00:00 GMT+1'
If you don't touch that setting and save the form again, this kind of
DateTime object is created:
dt = DateTime('2011/03/09 11:00:00 GMT+1')
dt.timezoneNaive()
False
dt.timezone()
'GMT+1'
dt.asdatetime()
datetime.datetime(2011, 3, 9, 11, 0, tzinfo=StaticTzInfo 'GMT+1')
If I set a date property to '2011/03/09 11:00:00', I expect it stays
marked as offset-naive if I save it twice. So I think the 'Properties'
tab should show '2011/03/09 11:00:00' without time zone if the object is
marked as offset-naive.
But maybe other people expect the time zone doesn't change and don't
care about naive or not. This creates a naive DateTime object with a
different time zone:
dt = DateTime('2011-03-09 11:00:00')
dt.timezoneNaive()
True
dt.timezone()
'GMT+0'
Currently the time zone is preserved, but not the naive marker:
dt = DateTime('2011/03/09 11:00:00 GMT+0')
dt.timezoneNaive()
False
dt.timezone()
'GMT+0'
With the fix I propose the naive marker is preserved, but not the time zone:
dt = DateTime('2011/03/09 11:00:00')
dt.timezoneNaive()
True
dt.timezone()
'GMT+1'
I would argue the people who don't care about naive or not should set
the time zone explicitly. In that case the DateTime objects are always
marked as offset-aware and the proposed fix will not affect them.
Any opinions?
Cheers,
Yuppie
___
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.publisher and ZPublisher: decoding form input
Hi! As discussed in a different thread, zope.publisher compatible decoding should be added to the ZPublisher. But does that code from zope.publisher make any sense? def _decode(self, text): Try to decode the text using one of the available charsets. if self.charsets is None: envadapter = IUserPreferredCharsets(self) self.charsets = envadapter.getPreferredCharsets() or ['utf-8'] for charset in self.charsets: try: text = unicode(text, charset) break except UnicodeError: pass return text Using getPreferredCharsets()[0] is correct because zope.publisher uses the same charset for encoding responses. (For ZPublisher we decided we don't want to support charset negotiation.) But what about the other charsets? AFAICS - There are no tests in zope.publisher for that fallback behavior. - That fallback behavior doesn't cause trouble because it is very rarely or never used. - The fact no error is raised by unicode(text, charset) doesn't mean we have the right charset. Here some background information: http://chardet.feedparser.org/docs/index.html - Returning the encoded strings if all attempts fail might not be the best choice. Proposal: Just use unicode(text, charset, 'replace') with the same charset used for encoding responses. If there are no objections, I'll implement it that way in ZPublisher. What about zope.publisher? I don't use zope.publisher, but I think it should always use 'utf-8' instead of trying to be smart. Cheers, Yuppie ___ 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] ZPublisher: using zope.formlib and z3c.form in Zope 2
Hi! Laurence Rowe wrote: On 2 March 2011 11:29, yuppiey.2...@wcm-solutions.de wrote: Laurence Rowe wrote: On 2 March 2011 10:00, yuppiey.2...@wcm-solutions.dewrote: Martin Aspeli wrote: I don't know what setPageEncoding() does, though. It sets a response Content-Type header with the first charset processInputs tries for decoding. Is the charset of the request necessarily the right choice for the response? In Plone we always serve UTF-8 encoded. getPreferredCharsets()[0] always returns 'utf-8' **if** UTF-8 is accepted. If 'utf-8' is not in getPreferredCharsets(), it is not very likely that the browser speaks UTF-8 and processInputs will not even try to decode with UTF-8. In that case it might be better to respond with an accepted encoding. If you serve differently encoded pages then you should set Vary: Accept-Charset. That seems to be correct. So you found a bug in zope.publisher and five.formlib. If they do charset negotiation, they have to set Vary. But then without normalization you'd get an explosion of different page variations. AFAICS that normalization can't be done by the server and we can't prevent ineffective caching. Without the Vary, it means that a visitor can poison the cache by supplying (only) a weird charset in Accept-Encoding. The page would then be served in this encoding, cached downstream, and if other visitor's browsers don't support that charset then they have a problem. That sounds like charset negotiation isn't a good idea and neither zope.publisher nor five.formlib should do it. If we don't negotiate the charset, we should still have a setPageEncoding method that overrides the ZPublisher default_encoding with UTF-8. But what does all that mean for the processInputs methods in Five (used by five.formlib) and in plone.z3cform? If we always send UTF-8, their current implementation doesn't make much sense to me. Don't know if we really should try to fall back to all the charsets mentioned in Accept-Charset. But at least we should *always* try UTF-8 decoding first. Cheers, Yuppie ___ 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] ZPublisher: using zope.formlib and z3c.form in Zope 2
Charlie Clark wrote: Am 04.03.2011, 08:58 Uhr, schrieb yuppiey.2...@wcm-solutions.de: If we always send UTF-8, their current implementation doesn't make much sense to me. Don't know if we really should try to fall back to all the charsets mentioned in Accept-Charset. But at least we should *always* try UTF-8 decoding first. I'm not sure if this is directly related but I remember Withers having a discussion (alright, shouting match) with Andreas about cycling through all kinds of encoding possibilities on the resolver. I can't find the thread at the moment but I think it related to the way templates could be edited TTW or how to handle situations of mixed encoding. I considered to propose that we don't use the IUserPreferredCharsets adapter at all in Zope 2 and remove its registration in ZCML. But then I noticed the code Andreas wrote in Products.PageTemplates.unicodeconflictresolver.PreferredCharsetResolver. I'm not going to start that discussion again. Cheers, Yuppie ___ 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] ZPublisher: using zope.formlib and z3c.form in Zope 2 - modified proposal
Hi again! Based on the discussion I modified my proposal: - Products.Five.browser.decode should be marked as deprecated. It implements charset negotiation without making sure the 'Vary' header is set correctly. Fixing this will cause other caching issues. - The setPageEncoding() function will not be replaced at all. We just rely on HTTPResponse.setBody() if the 'Content-Type' header is not set explicitly by the view. It is recommended to set default-zpublisher-encoding to utf-8. This is how plone.z3cform currently handles this. - The processInputs() function is replaced by a HTTPRequest method called postProcessInputs(). This method first tries to decode with HTTPRequest.default_encoding. If that causes failures, it falls back to the encodings returned by getPreferredCharsets(). - Directly after traversal ZPublisher.Publish.publish() calls request.postProcessInputs() if the object implements zope.publisher.interfaces.browser.IBrowserPage. If there are no objections I'll implement it that way on Zope trunk. Cheers, Yuppie ___ 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] ZPublisher: using zope.formlib and z3c.form in Zope 2
Hi! ZPublisher.Publish and zope.publisher.publish process form inputs differently. Zope 2 returns encoded strings unchanged if no converters are specified. zope.publisher converts encoded strings to unicode. One major reason why zope.formlib and z3c.form can't be used directly in Zope 2 is the fact they expect decoded form values. five.formlib uses special base classes and plone.z3cform monkey patches the base classes in z3c.form. Proposal: - Products.Five.browser.decode should be moved to ZPublisher. processInputs and setPageEncoding are publisher related code. - After traversal and before calling the object ZPublisher.Publish.publish should figure out if the object expects zope.publisher behavior. Either we use a new interface for this or we use zope.publisher.interfaces.browser.IBrowserPage: AFAICS in Zope 2 land only zope.formlib and z3c.form based views implement IBrowserPage. - If the object implements that interface, the request is post processed using processInputs and setPageEncoding. - plone.z3cform uses a modified version of processInputs and doesn't use setPageEncoding. Can anybody explain why? I guess that are no z3c.form specific reasons. Maybe the changes can be merged back to Zope? Does that make sense? I guess that kind of change should only be made on the trunk. Cheers, Yuppie ___ 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] ZPublisher: using zope.formlib and z3c.form in Zope 2
Hi Martin! Martin Aspeli wrote: - After traversal and before calling the object ZPublisher.Publish.publish should figure out if the object expects zope.publisher behavior. Either we use a new interface for this or we use zope.publisher.interfaces.browser.IBrowserPage: AFAICS in Zope 2 land only zope.formlib and z3c.form based views implement IBrowserPage. Isn't this in zope.browserpage now? No. - plone.z3cform uses a modified version of processInputs and doesn't use setPageEncoding. Can anybody explain why? I guess that are no z3c.form specific reasons. Maybe the changes can be merged back to Zope? processInputs() in Five was very buggy. I thought I'd merged those changes into Zope 2? Well. You were the last person who touched both. But the changes are quit different: http://svn.zope.org/Zope/trunk/src/Products/Five/browser/decode.py?rev=115280view=log http://svn.zope.org/plone.z3cform/trunk/plone/z3cform/z2.py?rev=109071view=log Is there still anything in plone.z3cform that should be merged into Zope 2? I don't know what setPageEncoding() does, though. It sets a response Content-Type header with the first charset processInputs tries for decoding. Cheers, Yuppie ___ 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] ZPublisher: using zope.formlib and z3c.form in Zope 2
Hi Charlie! Charlie Clark wrote: Am 02.03.2011, 12:29 Uhr, schrieb yuppiey.2...@wcm-solutions.de: getPreferredCharsets()[0] always returns 'utf-8' **if** UTF-8 is accepted. If 'utf-8' is not in getPreferredCharsets(), it is not very likely that the browser speaks UTF-8 and processInputs will not even try to decode with UTF-8. In that case it might be better to respond with an accepted encoding. I think you are drawing the wrong conclusion I did talk about getPreferredCharsets(), not about the Accept-Charset header. some browsers (Internet Explorer and Safari spring to mind but this will also be the behaviour in Opera from 11.10) simply don't have an accept-charset header and the W3C says this means you can throw anything at them, in which case UTF-8 is a good choice. You implemented this in getPreferredCharsets(), so that method says UTF-8 is accepted if no Accept-Charset header is set. And Five always used this line which has the same effect:: charsets = envadapter.getPreferredCharsets() or ['utf-8'] Cheers, Yuppie ___ 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] GenericSetup sans (Python) package?
Hi!
Alex Clark wrote:
I want to add GenericSetup (GS) profiles outside Python packages (i.e.
in the buildout via ZCML). Currently GenericSetup expects to be passed a
context which is (I think) the old-style Zope 2 product object in the
ZODB. But I can’t think of a reason why GS couldn’t be made to work sans
that requirement (I’m just speculating though, I haven’t looked at the
code yet).
---
Should I bother checking out the Products.GenericSetup source code to
see if something like this is possible?
Currently the ZCML directive expects a 'directory' relative to the
package root. The implementation looks up the package in the context
provided by zope.configuration. The directive only works if the
'package' attribute of the context is not None.
AFAICS the path() method of the context could be used if package is
None. The profile registry and all code using it should already work
without specifying a 'product' if a full 'path' is set instead of a
relative. ('product' is just an old name in the code. Could be any
Python package.)
I really, really, really, don't want to create a Python package just so
I can save a couple settings in my (Plone) site.
Usually I need more site specific stuff than just a profile, so I can't
see a big win.
Anyway: +1 for making the ZCML directive work if package is None
BTW: GenericSetup related questions are generally discussed on the
Zope-CMF list.
Cheers,
Yuppie
___
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 Tests: 67 OK, 2 Unknown
Tres Seaver wrote: Subject: UNKNOWN : Zope-trunk-alltests Python-2.6.5 : Linux From: Zope Tests Date: Sat Jan 8 01:21:40 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-January/028217.html These both look like: Running /usr/local/python2.6/bin/python ./bin/test --all Traceback (most recent call last): File ./bin/test, line 23, inmodule import zope.testrunner ImportError: No module named zope.testrunner The buildout output looks normal to me -- I'm not sure how to diagnose remotely. Zope 2 trunk now uses the latest testrunner version. This no longer works: /usr/local/python2.6/bin/python ./bin/test --all Should now be: /usr/local/python2.6/bin/python -S ./bin/test --all or just: ./bin/test --all Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 2: specifying Zope2 dependency
Hi!
Zope trunk (2.14) no longer ships with these Products:
Products.BTreeFolder2
Products.ExternalMethod
Products.MailHost
Products.MIMETools
Products.PythonScripts
Products.StandardCacheManagers
There are no separate Zope 2.12 compatible eggs for these Products
because they are part of the Zope2 2.12.X eggs.
Problem is: Several Products (e.g. CMF) exist that depend on these
Products and want to support Zope2 2.12, 2.13 and trunk. But AFAICS
there is no way to specify all dependencies correctly in setup.py. As a
workaround, CMF currently specifies the 'additional' Zope2 trunk
dependencies in buildout.cfg.
If there are no objections or better ideas, I'd like to add a
'zope212_compat' extra to Zope 2.12, 2.13 and trunk. For Zope 2.12 and
2.13 it would be empty, for trunk it would look like this:
extras_require={
'zope212_compat': [
'Products.BTreeFolder2',
'Products.ExternalMethod',
'Products.MailHost',
'Products.MIMETools',
'Products.PythonScripts',
'Products.StandardCacheManagers',
],
That would make it possible to specify the Zope2 dependency this way:
install_requires=[
'Zope2 [zope212_compat] = 2.12.15',
]
If Products drop Zope 2.12 support, they can switch to this:
install_requires=[
'Zope2 = 2.13.0',
'Products.MailHost', # required Products
]
Cheers,
Yuppie
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2: specifying Zope2 dependency
Hi Hanno! Hanno Schlichting wrote: With the mess of zope/zope.app distributions being part of Zope 2.12, I'd really like to get people away from it and stop maintaining it rather sooner than later. With Plone we are using CMF 2.2 and Zope 2.13 for the upcoming Plone 4.1. With the current roadmap, we'll likely be able to stop using Zope 2.12 in 6-9 months altogether. I think it makes sense to get a new CMF 2.3 in the next couple months as well, so there would be both CMF 2.2 and 2.3 available on Zope 2.13. Using CMF 2.2 for Plone 4.1 means we have to maintain CMF 2.2 for a long time and Zope 2.12 is the primary platform for CMF 2.2. So if you really want stop maintaining Zope 2.12 soon: Wouldn't it be better to release CMF 2.3 in time for Plone 4.1? Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2: specifying Zope2 dependency
Hi! Hanno Schlichting wrote: On Tue, Jan 4, 2011 at 2:53 PM, yuppiey.2...@wcm-solutions.de wrote: Using CMF 2.2 for Plone 4.1 means we have to maintain CMF 2.2 for a long time and Zope 2.12 is the primary platform for CMF 2.2. So if you really want stop maintaining Zope 2.12 soon: Wouldn't it be better to release CMF 2.3 in time for Plone 4.1? Plone 4.1 is long past the implementation deadline for new code. We would have had to have a CMF 2.3 beta release by late October to use it in Plone 4.1. Off-topic on this list, but for the record: Most CMF 2.3 changes are in code that is not used by Plone. AFAICS the only changes that might affect Plone are the SyndicationTool modifications. But those modifications are anyway not in a releasable state because they cause at least some BBB issues. If that's the reason why Plone 4.1 can't use CMF 2.3, I'd vote for backing out those changes. But if we get a CMF 2.3 release in the next couple months, we can get it into Plone 4.2, which should be out sometime at the end of this year. In Plone we only support one minor feature release (4.x) at the same time, so as soon as 4.2.0 is released maintenance of 4.0.x and 4.1.x ends. So what is the plan? Maintenance for Zope 2.12, CMF 2.2 and Plone 4.1 ends simultaneously at the end of this year? Or end Zope 2.12 maintenance earlier and make CMF 2.2 releases for an unmaintained platform? Or drop support for the major target platform between CMF 2.2.x and 2.2.y? Cheers, Yuppie ___ 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 Tests: 42 OK, 8 Failed
Hi! Patrick Gerken wrote: On Thu, Oct 7, 2010 at 10:50, Wichert Akkermanwich...@wiggy.net wrote: On 10/7/10 08:52 , Jens Vagelpohl wrote: For me personally the value has dropped so far that I am mostly ignoring those emails. They are hard to parse to begin with and there are just too many buildbot entries. Likewise. I've redirected all test-mails to /dev/null for a long time. Which projects do you not want to see in this summary mail? I think we can distinguish two categories of tests: 1.) Tests that are expected to run without failures. If one of these tests fails, that's a regression that needs to be fixed immediately. 2.) Tests that frequently fail. These show issues that need to be resolved in the long run. I only want to see the first category in the summary mail. The second category just produces noise on the list and makes it hard to recognize failures in the first category. Cheers, Yuppie ___ 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] z3c.recipe.i18n
Hi! Jan-Wijbrand Kolman wrote: This afternoon I merged the gary-0.8.0 branch for z3c.recipe.i18n. The recipe now uses and depends on zc.buildout-1.5.1 features. I'd like to release this merge as 0.8.0 as this make it possible to move grok and the groktoolkit over to zc.buildout-1.5.1. I guess this is also useful in the light of moving the ZTK itself to zc.buildout 1.5.1 at some point. Unless there are objections of course :) +1 But could you please make it more explicit that 0.8.0 drops support for zc.buildout 1.4? Your CHANGES.txt note is not clear about that and maybe install_requires should specify the new requirement explicitly. BTW: I just fixed some failing tests on Windows. Hope that doesn't mask any real issues. Cheers, Yuppie ___ 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] PageTemplate Interfaces in Zope 2.12
Hi! Chris Withers wrote: If I got to the Interfaces tab of a Page Template in the ZMI of a plain Zope 2.12 instance, it simply renders the template. Should that tab be there? The manage_interfaces view is universally useful and registered for all objects. But I can confirm that the Interfaces tab of Page Templates is broken. I guess this is a Page Template specific traversal issue and could be fixed. +1.0 for fixing the tab +0.2 for removing the tab if nobody wants to fix it Cheers, Yuppie ___ 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] unit test policy questions
Hi! Traditionally the last two lines of unit test files look like this: if __name__ == '__main__': unittest.main(defaultTest='test_suite') That makes it easy to run the tests of a specific file. But it doesn't work with tests that require the zope testrunner. AFAICS something like this is needed instead: if __name__ == '__main__': from zope.testing.testrunner import run run(['-m', 'test_foo', '--test-path', '.']) Questions: -- 1.) Is it still policy to add these lines? 2.) Is there a better solution for using zope testrunner than the one shown above? Cheers, Yuppie ___ 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] unit test policy questions
Martin Aspeli wrote: I never do either. I install zc.recipe.testrunner in a buildout and use bin/test, which picks up tests in modules automatically. Sure. But do you always run all tests it picks up while working on a specific test file? Or do you use bin/test with options that allow to run specific files? Cheers, Yuppie ___ 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] unit test policy questions
Hi Martin! Martin Aspeli wrote: On 29 July 2010 20:14, yuppiey.2...@wcm-solutions.de wrote: Martin Aspeli wrote: I never do either. I install zc.recipe.testrunner in a buildout and use bin/test, which picks up tests in modules automatically. Sure. But do you always run all tests it picks up while working on a specific test file? Or do you use bin/test with options that allow to run specific files? See the -s and -t options. :) Well. It's not that simple. Today I tried to modify Products.GenericSetup.tests.test_tool using CMF.buildout/trunk. I usually use the -m option, but that doesn't work in CMF.buildout because it already uses that option. So I tried to execute the module and noticed that's currently broken. The -s option doesn't allow to run a specific module. And if I use the -t option (-ttest_tool), most tests fail :( Cheers, Yuppie ___ 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] Unauthorized handling in Zope2
Hi!
Wichert Akkerman wrote:
Unauthorised is doing stupid things here:
(Pdb) p v
Unauthorized()
(Pdb) p unicode(v)
u''
(Pdb) p str(v)
*** UnicodeEncodeError: UnicodeEncodeError('ascii',
u'!DOCTYPE html...', 1175, 1176, 'ordinal not in range(128)')
I added an extra change (see diff below) to fix that, after which things
seemed to work.
Looks like my patch didn't work for you because of this:
http://bugs.python.org/issue6108 (fixed in Python 2.6.5)
I committed a modified Unauthorized patch that should work with all
supported Python versions:
http://svn.zope.org/?rev=97view=rev
And I hope together with the change in HTTPResponse your issue is
resolved now:
http://svn.zope.org/?rev=99view=rev
Cheers,
Yuppie
___
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] Unauthorized handling in Zope2
Hi! Wichert Akkerman wrote: v is the html as generated by my view. Reraising the exception transfers control to the bare except in ZPublisher.Publish.publish_module_standard, which generates the standard site error page and returns that. Could it be that your v is unicode? Please let me know if the attached patch fixes the issue. Cheers, Yuppie Index: public/src/zExceptions/unauthorized.py === --- public/src/zExceptions/unauthorized.py (revision 62) +++ public/src/zExceptions/unauthorized.py (working copy) @@ -43,7 +43,7 @@ provides are added to needed. if name is None and ( -not isinstance(message, StringType) or len(message.split()) = 1): +not isinstance(message, basestring) or len(message.split()) = 1): # First arg is a name, not a message name=message message=None Index: public/src/ZPublisher/HTTPResponse.py === --- public/src/ZPublisher/HTTPResponse.py (revision 62) +++ public/src/ZPublisher/HTTPResponse.py (working copy) @@ -800,7 +800,10 @@ b = v if isinstance(b, Exception): try: -b = str(b) +try: +b = str(b) +except UnicodeEncodeError: +b = self._encode_unicode(unicode(b)) except: b = 'unprintable %s object' % type(b).__name__ ___ 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] Unauthorized handling in Zope2
Hi!
Wichert Akkerman wrote:
Unauthorised is doing stupid things here:
(Pdb) p v
Unauthorized()
(Pdb) p unicode(v)
u''
(Pdb) p str(v)
*** UnicodeEncodeError: UnicodeEncodeError('ascii',
u'!DOCTYPE html...', 1175, 1176, 'ordinal not in range(128)')
I added an extra change (see diff below) to fix that, after which things
seemed to work.
Great!
Still, I can not see any good reason to reraise
Unauthorised exceptions if there is a valid exception view for them.
This approach feels like we are attacking the symptom instead of fixing
the problem.
Zope 2.12.4 was definitely broken:
401 Unauthorized responses MUST include a WWW-Authenticate header
field, see
http://tools.ietf.org/html/rfc2616#section-10.4.2
Re-raising the exceptions makes sure the post-processing in
HTTPResponse.exception is called. That is also expected by
CookieCrumbler and PAS.
A better fix would be to store the rendered exception value in the
response object instead of the exception object. That way we could
re-raise *all* exceptions as it was done in older Zope versions.
But this would have been a bigger refactoring with more risks to break
something else.
Cheers,
Yuppie
___
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] Unauthorized handling in Zope2
Hi! Wichert Akkerman wrote: On 4/20/10 15:17 , yuppie wrote: Wichert Akkerman wrote: I added an extra change (see diff below) to fix that, after which things seemed to work. Great! Can you commit that change along with your other changes? Yes. I'll write some more tests and commit it in time for the 2.12.5 release. Thanks for catching this issue early enough! Re-raising the exceptions makes sure the post-processing in HTTPResponse.exception is called. That is also expected by CookieCrumbler and PAS. The authentication dance between the publisher, request, PAS and CookieCrumbler really is a bit contrived :( An other advantage of the re-raising pattern is the fact that you can easily change the response type by raising a different exception inside the view. I plan to use that for replacing the nasty unauth redirect code in CookieCrumbler. The exception view will raise Redirect or Forbidden if you are already logged in. A better fix would be to store the rendered exception value in the response object instead of the exception object. That way we could re-raise *all* exceptions as it was done in older Zope versions. But this would have been a bigger refactoring with more risks to break something else. Perhaps something for 2.13 :) Yes. Perhaps ;) Cheers, Yuppie ___ 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] Unauthorized handling in Zope2
Hi! Wichert Akkerman wrote: I can't get an Unauthorized exception view to work with current Zope 2.12 svn. My approach was: - add a dummy PAS challenge plugin which does nothing, effectively delegating everything to my Unauthorized exception view - register a browser view for Unauthorized and return a proper error message there unexpectedly the result is a stock Zope2 site error page. What seems to happen is that everything works correctly, up to this point the zpublisher exception hook in Zope2.App.startup: if issubclass(t, Unauthorized): # Re-raise Unauthorized to make sure it is handled # correctly. We can't do that with all exceptions # because some don't work with the rendered v as # argument. raise t, v, traceback v is the html as generated by my view. Reraising the exception transfers control to the bare except in ZPublisher.Publish.publish_module_standard, which generates the standard site error page and returns that. I would have expected that HTTPResponse.exception uses v as the body of the returned page. Without further information I can't tell you why that doesn't work in your case. What is the reason for re-raising Unauthorized there? There is no special processing for it anywhere up in the call stack, so I can see no benefit to it. If I remove that code block so we always return the result of the view everything works as I would expect. I tried to fix the bug discussed in comments #15ff of https://bugs.launchpad.net/zope2/+bug/372632 Cheers, Yuppie ___ 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] Unauthorized handling in Zope2
Hi again! yuppie wrote: Wichert Akkerman wrote: v is the html as generated by my view. Reraising the exception transfers control to the bare except in ZPublisher.Publish.publish_module_standard, which generates the standard site error page and returns that. I would have expected that HTTPResponse.exception uses v as the body of the returned page. Without further information I can't tell you why that doesn't work in your case. Meanwhile I have some ideas what might go wrong. Tomorrow I'll have a closer look at it. Cheers, Yuppie ___ 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] RFC: Proposed new style for documenting and testing ZTK packages
Hi! Tres Seaver wrote: The refactoring I would like to see happen is to move the main narrative documentation into a separate, Sphinx-driven 'docs' directory in each ZTK package. As part of this move, we can start adding some of the really nice Sphinx features (cross references, indexing, auto-generation of API reference information, etc.). We can still leave the main line of the code illustrated using doctest-style blocks: Sphinx has nice support for testing those blocks *while building the docs*. [...] Thoughts? +1 in general, but I'm concerned about one thing: How can we make sure docs and code don't get out of sync? Do we have to run unittests *and* build the docs before each checkin? Will someone make sure buildbots and nightly tests report broken docs as well? Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2: ZPublisher exception handling
Hi! Tres Seaver wrote: yuppie wrote: yuppie wrote: In Zope 2.10 'raise_standardErrorMessage', 'zpublisher_exception_hook' and therefore 'Publish.publish' did always (re-)raise errors after rendering. That made sure 'HTTPResponse.exception' was called and CookieCrumbler was able to hook into 'HTTPResponse._unauthorized'. I'm now trying to figure out how this bug could be fixed: https://bugs.launchpad.net/zope-cmf/+bug/558340 For the record: Meanwhile I figured out that there is a related launchpad issue https://bugs.launchpad.net/zope2/+bug/372632 Do you have a suggestion for resolving those two bugs? The original issue reported in https://bugs.launchpad.net/zope2/+bug/372632 seems to be fixed. The issue discussed in comment #15 and later is basically the same as in https://bugs.launchpad.net/zope-cmf/+bug/558340. So there is only *one* issue: If errors are rendered by 'raise_standardErrorMessage' or by an error view they are not re-raised. In that case the error handling in 'publish_module_standard' and 'HTTPResponse.exception' is no longer invoked. I'm not sure how to resolve this. Approach 1: We try to restore the old behavior. The changes were made because the old machinery didn't work with exceptions like zope.publisher.interfaces.NotFound, but I'm optimistic we can find a less intrusive fix for that. Approach 2: The _unauthorized call seems to be the only part of the old error handling that people are actually missing. We could try to add a new hook for that and deprecate big parts of the old code. But is that old code really useless? and a workaround for the CookieCrumbler issue: http://dev.plone.org/collective/changeset/92340 Hmm, registering an exception view which re-raises the exception is definitely suggestive of something wrong in the plumbing. Yes. But *if* we don't want restore the old behavior, we could move CookieCrumbler's complete redirect logic into an error view. And get rid of _unauthorized. Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2: ZPublisher exception handling
yuppie wrote: In Zope 2.10 'raise_standardErrorMessage', 'zpublisher_exception_hook' and therefore 'Publish.publish' did always (re-)raise errors after rendering. That made sure 'HTTPResponse.exception' was called and CookieCrumbler was able to hook into 'HTTPResponse._unauthorized'. I'm now trying to figure out how this bug could be fixed: https://bugs.launchpad.net/zope-cmf/+bug/558340 For the record: Meanwhile I figured out that there is a related launchpad issue https://bugs.launchpad.net/zope2/+bug/372632 and a workaround for the CookieCrumbler issue: http://dev.plone.org/collective/changeset/92340 I also removed some useless code in 'raise_standardErrorMessage': http://svn.zope.org/?rev=110801view=rev http://svn.zope.org/?rev=110806view=rev Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 2: ZPublisher exception handling
Hi! Summary: In Zope 2.10 'raise_standardErrorMessage', 'zpublisher_exception_hook' and therefore 'Publish.publish' did always (re-)raise errors after rendering. That made sure 'HTTPResponse.exception' was called and CookieCrumbler was able to hook into 'HTTPResponse._unauthorized'. I'm now trying to figure out how this bug could be fixed: https://bugs.launchpad.net/zope-cmf/+bug/558340 Some details: = In Zope 2.10 and earlier the code did (re-)raise errors this way: raise error_type, error_value, traceback 'error_type' is the original error class, 'error_value' the rendered error message. Python creates a new error instance, basically trying to do this: error_instance = error_type(error_value) That doesn't work if the error class constructor requires more than one argument. This was the first change that broke the old behavior: http://svn.zope.org/?view=revrev=77459 The comment in Zope2/App/startup.py is interesting because it says raise the rendered value while the code actually *returns* it: # Lookup a view for the exception and render it, then # raise the rendered value as the exception value # (basically the same that 'raise_standardErrorMessage' # does. I guess the checkin message for http://svn.zope.org/?view=revrev=92767 explains why: Rather nasty fix to work around Zope 3 exceptions that have more than one positional argument on the constructor. The old machinery doesn't work with ZTK exceptions like zope.publisher.interfaces.NotFound because they take additional arguments and have are more complex __str__ method. There is an inconsistency in revision 92767 ( http://svn.zope.org/Zope/trunk/lib/python/OFS/SimpleItem.py?rev=92767view=diffr1=92767r2=92766 ): The checkin message says: work around Zope 3 exceptions that have *more than one* positional argument. I think that's correct. The comment in SimpleItem.py says something different: # Can we re-raise the exception with a rendered-to-HTML # exception value? To be able to do so, the exception # constructor needs to be able to take more than two # arguments (some Zope exceptions can't). The code follows that comment, so 'can_raise' is sometimes wrong. E.g. can_raise is True for zope.publisher.interfaces.NotFound, but re-raising with the rendered value as only argument doesn't work. Proposal: = We could try to fix bugs like the one mentioned above. And we could restore the old behavior for normal Zope 2 exceptions, fixing the CookieCrumbler issue. But the whole thing looks like a big mess. I think we should try to find a way to treat all kinds of errors the same way. I see two possible approaches: 1.) Stop re-raising errors. Always return rendered values and pass them on to the places where the errors are currently catched. 2.) Re-raise the original errors. And store the rendered value somewhere else. Maybe in the response object. What do you think? Any comments are welcome. Cheers, Yuppie ___ 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] Comply with repository policy ?
Hi! Tres Seaver wrote: o Run the automated fixups:: $ /path/to/zrp/bin/zope-org-fix-project . ...list of automated fixups ... Just in case *someone* cares: zope-org-fix-project was written for copyright headers with a specific layout. Depending on the actual layout it removes the sentence All Rights Reserved. partially or completely. So depending on a layout difference (line break or not) it produces copyright headers with different content. Doesn't make any sense to me, but the people I already asked don't care. Cheers, Yuppie ___ 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] Comply with repository policy ?
Hi! Tres Seaver wrote: yuppie wrote: Tres Seaver wrote: So depending on a layout difference (line break or not) it produces copyright headers with different content. Doesn't make any sense to me, but the people I already asked don't care. The All Rights Reserved is a little senseless, since the following language turns around and says that the files are covered by the ZPL. I'm not opposed to removing that phrase. What I don't like is the fact that it is removed randomly based on a bug in a script that is made for a different purpose. I think a change like that should be based on an official policy change, including new coding style guidelines: http://docs.zope.org/zopetoolkit/codingstyle/python-style.html#license-statement-module-docstring Cheers, Yuppie ___ 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-Checkins] SVN: Zope/branches/tseaver-clarify_install_docs/doc/ Split out docs for 'normal' installation from those using 'zc.buildout'.
Hi Tres! Tres Seaver wrote: I recommend virtualenv to anybody who just wants to install and run the Zope2 appserver, without needing to drink a lot of kool-aid: just install it from PyPI, run 'mkzopeinstance', and you're done. Who are these people? Why do they want to install and run Zope2? Is Zope2 in any way useful for non-developers? Is pure TTW development the best way to get started? Or do you recommend virtualenv as well for small file-system based projects? Cheers, Yuppie ___ 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-Checkins] SVN: Zope/branches/tseaver-clarify_install_docs/doc/ Split out docs for 'normal' installation from those using 'zc.buildout'.
Hi Tres!
Tres Seaver wrote:
Chris Withers wrote:
By all means, document virtualenv as an option, but blessing it as the
one true way is a bit much...
I'm also surprised that you propose to make this *the* recommended way.
Here's my rationale:
- - The docs are intended primarily for folks who want to install and
run Zope, rather than hack on it.
So you recommend virtualenv for administrators and buildout for
developers? Or where do you draw the line? And when do you recommend to
switch from one setup to the other? Or do you always recommend virtualenv?
I thought zc.buildout is preferred by most people in the Zope community.
- - zc.buildout is *super* heavyweight compared to virtualenv
- - zc.buildout creates an environment which is puzzling as hell for
anybody who hasn't already drunk the koolaid ('parts'? 'eggs'?
WTF?)
virtualenv is also puzzling if you are not familiar with it. Using
activate and deactivate or the right paths isn't much easier to learn
than using zc.buildout.
- - virtualenv, or something damn near it, is likely to land in Python
itself.
- - Nearly anybody else in the Python world is more likely to be
familiar with the virtualenv stuff than with buildout.
But not everybody in the Python world is familiar with virtualenv. Why
should we encourage people to make themselves familiar with virtualenv
instead of zc.buildout?
- - We have two alternate zc.buildout scenarios (install Zope + run
mkzopeinstance vs. self-contained environment). The first has no
real advantage over the virtualenv one, except being able to
run buildout to update the software (heaven help you if you forget
to configure the index properly!). The second leaves you without
the annotated config file, a *major* faux pas.
I consider the self-contained scenario still as experimental. Following
the instructions requires much more typing than the other scenarios. But
I'm optimistic it can and will be improved.
Cheers,
Yuppie
___
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-Checkins] SVN: Zope/branches/tseaver-clarify_install_docs/doc/ Split out docs for 'normal' installation from those using 'zc.buildout'.
Hi Chris! Chris Withers wrote: yuppie wrote: I consider the self-contained scenario still as experimental. You might, I don't. I've deployed this happily in production with a few customer now. Just because you don't happen to like it yourself, please don't belittle it... I didn't mean to belittle it. 'experimental' is nothing negative. I'm happy people like you are working on and with this approach. But IMHO some details like the role of the annotated config file or if a paster template would make things easier are not yet fleshed out enough to make it *the* recommended scenario. Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2: circular import
Tres Seaver wrote: But where would be a good place for TaintedString? It is too small to create a package just for that. In which existing package would it fit? Or should we just add a copy of TaintedString to DocumentTemplate? Put it in Shared.DC.Scripting? ZPT and DTML already depend on it, I think (oops, no, ZPT and PythonScript, but not DTML). Or just put it in a module / package in the Zope2 distribution's 'src' directory. It is now in Shared.TaintedString. If someone knows a better place, feel free to move it there. ZPublisher.TaintedString was definitely the wrong place. Cheers, Yuppie ___ 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] SVN: Zope/trunk/ Moved zope.formlib / zope.app.form integration into a separate package called five.formlib.
Hi! Tres Seaver wrote: Hanno Schlichting wrote: But in order to get Zope2 really app-free we need to drop the direct five.formlib dependency at some point, or we still pull things in via transitive dependencies. Is deprecating in 2.13 and removal in 2.14 ok? +1 Since it doesn't make sense to mark five.formlib and zope.app.* as deprecated, it would be helpful to announce that ZTK and Zope 2 maintainers will no longer support these packages after Zope 2.12.3. Or does anyone have a different preference? Is it ok to backport this to 2.12? +1 for shipping Zope 2.12.3 with five.formlib -1 for adding new deprecation warnings in a bugfix release +1 to dropping it in Zope 2.13: folks who are using it will just need to add one egg to their buildouts (or their install_requires) and adjust imports, right? Anyway, in the interests of getting to a clean runs on ZTK label sticker on the box, onward and upward. Why not following the normal procedure? At some point in the past we decided to add formlib support to Zope 2. That's a commitment. We should not drop features just like that. Zope 2.13 can still have the runs on ZTK label if it ships with additional packages. Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 2: circular import
Hi! I stumbled over a circular import in Zope 2. in DocumentTemplate.DT_Util: from ZPublisher.TaintedString import TaintedString this triggers ZPublisher.BaseRequest with: from AccessControl.ZopeSecurityPolicy import getRoles this triggers AccessControl.DTML with: from DocumentTemplate import DT_Util With try/except imports and the right import order this works, but it would be better to break up that circle. At first glance the solution is simple: TaintedString doesn't have any dependencies and is used by DocumentTemplate and ZPublisher. So it should be moved to a place where both modules can use it without triggering countless imports. But where would be a good place for TaintedString? It is too small to create a package just for that. In which existing package would it fit? Or should we just add a copy of TaintedString to DocumentTemplate? Any ideas? Cheers, Yuppie ___ 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] SVN: Zope/trunk/ Moved zope.formlib / zope.app.form integration into a separate package called five.formlib.
Hi! Hanno Schlichting wrote: On Sun, Dec 27, 2009 at 5:43 PM, yuppie y.2...@wcm-solutions.de wrote: Why not following the normal procedure? At some point in the past we decided to add formlib support to Zope 2. That's a commitment. We should not drop features just like that. I think five.formlib is better served by being a separate distribution that can evolve on its own, much like we do it with five.localsitemanager. I don't understand this as dropping the support, but as shifting the maintenance to a different group. Both CMF and Plone use formlib today and have both come up with additions and new features for it. I want those to go into five.formlib. Having the code in Zope2 seems to prevented people from doing so. On the other side many people in the Plone community have started using z3c.form instead of formlib and it looks like all of Plone will shift to that. Exactly. And I expect CMF will also switch to z3c.form. Once that happens I don't want to have formlib to still be there as a dependency of Zope2 for all eternity. Agreed. I did just argue against the fast removal Tres proposed. But five.formlib will only evolve for a short period. Soon it will become a pure legacy package. Nothing we want to recommend for new projects. And in the long run five.formlib and its non-ZTK dependencies will become unmaintained. Cheers, Yuppie ___ 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] z3c.recipe.i18n tests fail
Christian Zagrodnick wrote: On 2009-12-01 16:36:50 +0100, yuppie y.2...@wcm-solutions.de said: Christian Zagrodnick wrote: AttributeError: 'NoneType' object has no attribute 'location' Should be fixed now. Yuppie Thanks! And it was such an easy fix! :) Well. Actually I didn't test with a clean buildout and removed 'zope.contenttype' as well because it wasn't part of my dependencies. But you noticed and fixed that already :) Cheers, Yuppie ___ 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] z3c.recipe.i18n tests fail
Christian Zagrodnick wrote:
Error in test /private/tmp/trunk/src/z3c/recipe/i18n/README.txt
Traceback (most recent call last):
File /Users/zagy/development/python/lib/python2.6/unittest.py, line
270, in run
self.setUp()
File
/Users/zagy/development/eggs/zope.testing-3.8.3-py2.6.egg/zope/testing/doctest.py,
line 2289, in setUp
self._dt_setUp(test)
File /private/tmp/trunk/src/z3c/recipe/i18n/tests.py, line 43, in setUp
zc.buildout.testing.install('zope.app.publisher', test)
File
/Users/zagy/development/eggs/zc.buildout-1.4.2-py2.6.egg/zc/buildout/testing.py,
line 464, in install
if dist.location.endswith('.egg'):
AttributeError: 'NoneType' object has no attribute 'location'
Should be fixed now. Yuppie
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.1 release
Hi! Chris Withers wrote: yuppie wrote: I hope Chris W. will fix this. I'll try and have a look before Nov 1st. Great! He is more familiar with the zopectl code and he already fixed some other regressions caused by his refactoring. I have? News to me... I don't want to argue about this. I might be wrong. But these things did work for me in 2.12.0 so I consider them regression issues: https://bugs.launchpad.net/zope2/+bug/440490 https://bugs.launchpad.net/zope2/+bug/443005 AFAICT my patch fixes the issue, but it fixes it in the wrong place. And it would cost me some time to figure out how to do this right. Your patch seems a bit odd... Did I say something different? I never proposed to check it in. I just thought it might be useful for understanding the issue. If I understand what you're trying to report: when using zopectl interactively (on windows? on linux? on both?) Quoting from my bug report: Windows only some commands (which commands?) Quoting from my bug report: most commands, e.g. after start, restart and stop cause the interactive session to end when you'd expect them not to? Exactly. If so, perhaps you could update the issue with the requested information? The requested information is already in the bug report. Please let me know if you need additional information. Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.1 release
Hi! Andreas Jung wrote: Am 26.10.09 22:28, schrieb yuppie: Andreas Jung wrote: I plan to release Zope 2.12.1 on November 2nd, 2009. Objections or open issues? I'd like to nominate this bug: https://bugs.launchpad.net/zope2/+bug/461446 You're going to fix it? I hope Chris W. will fix this. He is more familiar with the zopectl code and he already fixed some other regressions caused by his refactoring. AFAICT my patch fixes the issue, but it fixes it in the wrong place. And it would cost me some time to figure out how to do this right. Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
Hi Chris!
Chris Withers wrote:
(updating myself much much later)
(replying much much later)
Chris Withers wrote:
yuppie wrote:
You ripped my sentence out of context. We were talking about Zope
2.12. And Zope 2.12 currently doesn't use buildout for setting up
instances.
Sure it does. I've published the recipe. There's no more needed than
that...
Your recipe is not published as part of Zope 2.12.
I'm not sure it needs to...
It will be once Jens cranks the handle:
http://svn.zope.org/Zope/branches/2.12/doc/INSTALL.rst?rev=104817view=auto
And it doesn't work on Windows.
Have you tried it?
...if you had, you would have noticed that the Win32 service stuff as
broken, even without using buildout.
No. I did have tried with mkzopeinstance and zopeservice.py. And it did
work for me.
I've now fixed that, and I'm happy to report that the buildout-based
instances work just fine on Windows, and buildout instance or not, you
no longer need that silly zopeservice.py file in your instance.
That's a great improvement. I just found a small regression, see
https://bugs.launchpad.net/zope2/+bug/461446
So, no excuse for needing mkzopeinstance and its ilk anymore ;-)
In some situations I still prefer the classic way to create instances.
You might have noticed that the Creating a classic Zope Instance
section in INSTALL.rst is much simpler than the Creating a
buildout-based Zope Instance section.
And there is still the question about the right way to work with dev
eggs. I quote your question from an other mail in this thread because I
didn't answer it so far:
The dev eggs are local to my dev buildout, but not local to the test
instances.
What does this actually mean? For me, a dev egg is usually just an svn
checkout, specified in {buildout:develop}. For me, they're never usually in
any buildout, unless the package itself is buildout-driven and I'm actually
developing it, but that has nothing to do with my test instances... That
said, I often use a few dev eggs that aren't buildout driven at all, so I
really fail to see your point...
http://svn.zope.org/repos/main/CMF.buildout/trunk has a src directory
with several svn externals. Buildout includes the dev eggs from the src
directory.
http://svn.plone.org/svn/plone/buildouts/plone-coredev/trunk uses
mr.developer to use the src directory in a similar way.
The dev eggs are created before running the buildout command, but they
belong to a specific buildout.
That sometimes makes buildout-based Zope instances more clumsy than
classic instances.
Cheers,
Yuppie
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12.1 release
Andreas Jung wrote: I plan to release Zope 2.12.1 on November 2nd, 2009. Objections or open issues? I'd like to nominate this bug: https://bugs.launchpad.net/zope2/+bug/461446 It's a regression. Cheers, Yuppie ___ 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] Proposal: quit importing zope.app.schema.vocabulare in Products.Five
Hi Tres! Tres Seaver wrote: I don't know what the purpose of the following checkin was: http://svn.zope.org/Zope/trunk/?rev=85827view=rev See https://mail.zope.org/pipermail/zope-dev/2008-April/031691.html but the tests all pass if I rip out the import, and Zope starts. I don't know what code in Zope2 expects the ZopeVocabularyRegistry to be registered. Can you remember what needed it? A wrong import in CMFCalendar did mask the problem, but I just fixed that and now you can see some CMF tests failing if that import is removed in Five. Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
Hi Chris!
Chris Withers wrote:
yuppie wrote:
yuppie wrote:
Currently buildout is just used to set up the software.
Wrong. The buildout I posted, which uses no fancy recipes, sets up an
instance. The egg cache, as such, is the software...
You ripped my sentence out of context. We were talking about Zope 2.12.
And Zope 2.12 currently doesn't use buildout for setting up instances.
Sure it does. I've published the recipe. There's no more needed than that...
Your recipe is not published as part of Zope 2.12. And it doesn't work
on Windows.
[...]
These
buildouts are more 'software' than 'instance'. Maybe with that scenario
my assertions make more sense to you?
Nope. As I said, The Zope 2.12 software will never be in such a
buildout, just used by it. As such, the egg cache wherever and however
you have it becomes the Zope 2.12 software... Anything in the buildout
is software that is local to that instance, like Products or External
Methods used to be in days of old...
Are you ignoring the fact that buildouts with several dev eggs exist? Or
do you define all dev eggs as local to the instance?
For development I regularly use one dev buildout with several different
test instances. The dev eggs are local to my dev buildout, but not local
to the test instances.
I meant I nicer way of passing in the location of zope.conf...
If you create the instance in the same step your solution doesn't look
that bad.
I don't know what you mean by this...
You propose to create the entry point and the instance in the same step.
And you have these lines in your buildout.cfg:
initialization =
import sys
sys.argv[1:1] = ['-C','${buildout:directory}/etc/zope.conf']
Why are you not happy with that solution?
we can make it unnecessary to specify the interpreter.
When runzope and zopectl are built by buildout, this is already the
case... One python is used for both...
No. Currently you also need 'zopepy' (or 'py' in your case).
They're all the same python...
Exactly. But if we always use the same Python, why do we have to specify
it in several places?
Huh? You don't...
Your buildout.cfg creates an interpreter entry point 'py'. Your
zope.conf.in specifies python $INSTANCE/bin/py.
But the zopectl entry point already contains all the information it
needs. runzope doesn't depend on 'py'. Why does zopectl have to look up
the interpreter path in zope.conf und use 'py'?
Cheers,
Yuppie
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
Hi Chris! Chris Withers wrote: yuppie wrote: Currently buildout is just used to set up the software. Wrong. The buildout I posted, which uses no fancy recipes, sets up an instance. The egg cache, as such, is the software... You ripped my sentence out of context. We were talking about Zope 2.12. And Zope 2.12 currently doesn't use buildout for setting up instances. Of course buildout in general is used in many ways and often for setting up instances. is used to set up instances. And while I see that using buildout for setting up everything in one step has some advantages, it's not the best pattern for all use cases. So tell us where it's not best rather than just asserting that such a use case exists ;-) mkzopeinstance helps to draw a line between software and data. No it doesn't. Plenty of software can live in an instance. IMNSHO, buildout does a *better* job of drawing a line between software and data... that's important for distributors who want to distribute generic software, not user specific instance setups. Distributors just want a tarball or similar, let them use zc.sourcerelease and have a slightly different buildout.cfg, or even default.cfg, which uses that tarball as the source of eggs rather than PyPI... And sometimes it is useful to link an existing instance to a new buildout by updating some paths in instance/bin. I don't understand this. Please explain more... Or to create several instances based on one buildout. Why? I guess the scenario you have in mind is a lightweight buildout that just contains some .cfg files describing the instance. There is nothing wrong about using buildout that way, but maybe it's wrong to make it the only supported way. The scenario I have in mind is a buildout that contains several development eggs. In that case it is expensive to update and rebuild a buildout. And you might have local changes in that buildout. These buildouts are more 'software' than 'instance'. Maybe with that scenario my assertions make more sense to you? Cool. If only the zope2 egg could expose these now, it would make the buildout.cfg simpler... just the matter of passing in the config. I wonder if anyone can think of a nicer way of doing that? runzope and zopectl are defined as entry points: http://svn.zope.org/Zope/tags/2.12.0b4/setup.py?rev=102515view=auto Or did you mean something else? I meant I nicer way of passing in the location of zope.conf... If you create the instance in the same step your solution doesn't look that bad. And if you use mkzopeinstance the command line option seems to be the right way to specify zope.conf. we can make it unnecessary to specify the interpreter. When runzope and zopectl are built by buildout, this is already the case... One python is used for both... No. Currently you also need 'zopepy' (or 'py' in your case). They're all the same python... Exactly. But if we always use the same Python, why do we have to specify it in several places? 4.) How do you create zopeservice.py for Windows? What's Windows? Seriously though, I haven't needed to run Zope 2.12 on Windows, so I don't know... But we have to support Windows. And I was able to get zopeservice.py running with mkzopeinstance. *If* we decide to use buildout the way you propose, someone has to figure out how to create zopeservice.py without mkzopeinstance. Sure, I can't imagine it's a particularly hard problem, it's just not one the I'm interested in solving... That makes two of us. If nobody wants to do the work, your proposal is moot. Cheers, Yuppie ___ 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] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
Hi Chris!
Chris Withers wrote:
yuppie wrote:
ZDCTL=$SOFTWARE_HOME/Zope2/Startup/zopectl.py
exec $PYTHON $ZDCTL -C $CONFIG_FILE $@
I wish we could just bless buildout as the way to set up Zope 2.12,
then mkzopeinstance becomes moot.
Not everybody agrees with that. But nevertheless, both approaches can
learn from each other and become more similar.
Are you one of the people who doesn't agree? If so, what's your problem
with buildout? Hopefully we can sort that rather than having to maintain
two ways of doing things...
IMHO it is a good thing to try to keep the setup procedure as generic as
possible. Even though I don't use the virtualenv/easy_install pattern.
But the more important question is *how* buildout is used:
Currently buildout is just used to set up the software. mkzopeinstance
is used to set up instances. And while I see that using buildout for
setting up everything in one step has some advantages, it's not the best
pattern for all use cases.
mkzopeinstance helps to draw a line between software and data. AFAICS
that's important for distributors who want to distribute generic
software, not user specific instance setups. And sometimes it is useful
to link an existing instance to a new buildout by updating some paths in
instance/bin. Or to create several instances based on one buildout.
1.) mkzopeinstance now also uses entry points for runzope and zopectl.
zopectl did have some code in the __name__ == '__main__' section, so I
added a small 'run' wrapper for 'main':
http://svn.zope.org/Zope/trunk/src/Zope2/Startup/zopectl.py?rev=102009r1=101795r2=102009
Interesting. I never noticed that... Hopefully that change will make it
into Zope 2.12 final?
Yes. I made that change on the 2.12 branch as well.
2.) The runzope and zopectl scripts created by mkzopeinstance are now
basically small wrappers that pass the config file location to the entry
point scripts.
Cool. If only the zope2 egg could expose these now, it would make the
buildout.cfg simpler... just the matter of passing in the config. I
wonder if anyone can think of a nicer way of doing that?
runzope and zopectl are defined as entry points:
http://svn.zope.org/Zope/tags/2.12.0b4/setup.py?rev=102515view=auto
Or did you mean something else?
Maybe
we can make it unnecessary to specify the interpreter.
When runzope and zopectl are built by buildout, this is already the
case... One python is used for both...
No. Currently you also need 'zopepy' (or 'py' in your case). zopectl
uses self.options.python to run several commands. Quoting some lines
from zopectl:
def get_startup_cmd(self, python, more):
cmdline = ( '%s -c from Zope2 import configure;'
'configure(\'%s\');' %
(python, self.options.configfile)
)
return cmdline + more + '\'
def do_debug(self, arg):
cmdline = self.get_startup_cmd(self.options.python + ' -i',
'import Zope2; app=Zope2.app()')
print ('Starting debugger (the name app is bound to the
top-level '
'Zope object)')
os.system(cmdline)
4.) How do you create zopeservice.py for Windows?
What's Windows? Seriously though, I haven't needed to run Zope 2.12 on
Windows, so I don't know...
But we have to support Windows. And I was able to get zopeservice.py
running with mkzopeinstance. *If* we decide to use buildout the way you
propose, someone has to figure out how to create zopeservice.py without
mkzopeinstance.
Cheers,
Yuppie
___
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] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
Hi Chris! Chris Withers wrote: yuppie wrote: SOFTWARE_HOME no longer exist in Zope 2.12, all the software is now somewhere on sys.path. So this no longer works in zopectl: ZDCTL=$SOFTWARE_HOME/Zope2/Startup/zopectl.py exec $PYTHON $ZDCTL -C $CONFIG_FILE $@ I wish we could just bless buildout as the way to set up Zope 2.12, then mkzopeinstance becomes moot. Not everybody agrees with that. But nevertheless, both approaches can learn from each other and become more similar. If you dig back through the archives, you'll find the buildout.cfg I came up with that works exactly as it should. Thanks for the pointer. I was not aware of this thread: http://mail.zope.org/pipermail/zope-dev/2009-April/035973.html Some random thoughts: 1.) mkzopeinstance now also uses entry points for runzope and zopectl. zopectl did have some code in the __name__ == '__main__' section, so I added a small 'run' wrapper for 'main': http://svn.zope.org/Zope/trunk/src/Zope2/Startup/zopectl.py?rev=102009r1=101795r2=102009 2.) The runzope and zopectl scripts created by mkzopeinstance are now basically small wrappers that pass the config file location to the entry point scripts. They still set INSTANCE_HOME, but that is redundant if we always set INSTANCE_HOME in zope.conf. 3.) And the zopectl script still sets the PYTHON interpreter. You specify it in zope.conf. I can't see a reason why someone would want to run zopectl with a different interpreter than the Zope instance. Maybe we can make it unnecessary to specify the interpreter. It's just a bit tricky to pass the whole Python path to the subprocess. At least I couldn't figure out a simple and reliable solution. 4.) How do you create zopeservice.py for Windows? Cheers, Yuppie ___ 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] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
Andreas Jung wrote: On 23.07.09 12:10, yuppie wrote: Any thoughts? Is the 2.12 branch still open for changes like that? Go ahead. I also had to fix a similar issue some days ago inside Zope startup code. Done. http://svn.zope.org/?rev=102230view=rev http://svn.zope.org/?rev=102231view=rev But I couldn't figure out a solution for the zopeservice.py (Windows): The path to the Zope2 egg (ZOPE2PATH) is required to import from nt_svcutils.service. If the Zope2 egg is updated zopeservice.py of each Windows instance has to be updated as well. Cheers, Yuppie ___ 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 2.12: mkzopeinstance, runzope and zopectl - a small proposal
Hi! SOFTWARE_HOME no longer exist in Zope 2.12, all the software is now somewhere on sys.path. So this no longer works in zopectl: ZDCTL=$SOFTWARE_HOME/Zope2/Startup/zopectl.py exec $PYTHON $ZDCTL -C $CONFIG_FILE $@ Therefore mkzopeinstance now creates something like this: ZDCTL=/path/to/eggs/Zope2-2.12.0b3-py2.5-linux-i686.egg/Zope2/Startup/zopectl.py exec $PYTHON $ZDCTL -C $CONFIG_FILE $@ Problem: - the code in mkzopeinstance.py that looks up the Zope2 path fails on some platforms - if the software is updated, you have to change the paths in runzope and zopectl of each instance Solution: - 1.) Add two new entry points in setup.py: runzope=Zope2.Startup.run:run zopectl=Zope2.Startup.zopectl:run If the software is installed, executable runzope and zopectl files are created in the bin directory. That should work with zc.buildout and with easy_install. 2.) Modify the runzope and zopectl files created by mkzopeinstance: The result should look like this: ZDCTL=/path/to/install/bin/zopectl exec $ZDCTL -C $CONFIG_FILE $@ mkzopeinstance would make the assumption that executable runzope and zopectl files exist in the same directory as mkzopeinstance itself. Risks: -- - mkzopeinstance has a --python option. The specified Python interpreter will no longer be used to execute runzope or zopectl. - uses cases might exist that no longer work after that change Any thoughts? Is the 2.12 branch still open for changes like that? Cheers, Yuppie ___ 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] z3c.recipe.i18n and zope.app.locales.extract
Roger Ineichen wrote: What about testing it like this: We remove the 'else' part and wait until someone complains. In that case we have a scenario for testing and fixing the issue. If nobody complains, the 'else' part was indeed useless. The current code doesn't work for me because 'src' is found but not the right place to split the path. I'm fine with that. I can test the changes with the project which I used as base when I wrote the path cleanup code. I checked in that change. Can you please test? Thanks! Yuppie ___ 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] z3c.recipe.i18n and zope.app.locales.extract
Hi Roger! 1.) running tests - Proposal: Remove those two lines in test.py. Done. 2.) looking up the product version -- Proposal: Catch the error. Return an empty string if version is not found. The problem was somewhere different: Caused by wrong dependencies zope.app.applicationcontrol was not available. After fixing the dependencies the method works without error and 'Development/Unknown' is returned with Zope 2. That's sufficient for me. 3.) customizing the .pot header --- Proposal: The easiest and most flexible way to customize this seems to be an option that allows to specify a file that contains the pot_header template. This is still missing. I plan to subclass POTMaker in z3c.recipe.i18n instead of modifying zope.app.locales.extract. 4.) looking up basePath --- Proposal: Use the 'if' code for all packages. Done. (At least if nobody complains.) 5. writing makers - Proposal: Pass in the additional arguments and fall back to the old signature for BBB. Done. I also added site_zcml as argument. What about wrapping py_strings, zcml_strings and tal_strings in functions that implement the new interface? This would make it possible to add them to the makers list and call them in the same loop. Cheers, Yuppie ___ 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] z3c.recipe.i18n and zope.app.locales.extract
Roger Ineichen wrote: 5. writing makers - Proposal: Pass in the additional arguments and fall back to the old signature for BBB. Done. I also added site_zcml as argument. What about wrapping py_strings, zcml_strings and tal_strings in functions that implement the new interface? This would make it possible to add them to the makers list and call them in the same loop. Yes, why not. Probably we should do this together with a refactoring and change/enhance the method signature for the pot makers. I'm not sure I understand what you mean. What exactly do you want to change/enhance? This checkin already changed/enhanced the way pot makers are called: http://svn.zope.org/?rev=101958view=rev Do you want to improve that further or do you propose to modify py_strings, zcml_strings and tal_strings? They all have currently different signatures. I can't see a way to unify that in a backwards compatible way. That's why I proposed to wrap them in new z3c.recipe.i18n specific functions. I propose I start with the changes I have in mind. Of course you can improve that further after I'm done. Cheers, Yuppie ___ 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] z3c.recipe.i18n and zope.app.locales.extract
Hi Roger,
Thanks for your feedback!
Roger Ineichen wrote:
-Ursprüngliche Nachricht-
2.) looking up the product version
--
POTMaker._getProductVersion() doesn't work for me.
zope.app.applicationcontrol is not used by Zope 2 and is not
part of the specified dependencies. This raises an error.
Proposal: Catch the error. Return an empty string if version
is not found.
Sounds good to me as a workarround
Probably we should try to use the package version of the egg
which uses the i18n recipe?
Not every buildout is itself an egg. So in any case we need a fallback.
In my use case I plan to set the version manually in the pot_header
template. So I don't need the version lookup.
i18nextract.main() initializes POTMaker this way:
# setup pot maker
maker = POTMaker(output_file, '')
The second argument is the path that is used by
POTMaker._getProductVersion() to look up a 'version.txt' file. Maybe we
could use a better path than ''. But I'll leave it to someone else to
figure that out.
4.) looking up basePath
---
i18nextract.main() contains these lines:
# add maker for each given path
for pkgName, path in eggPaths:
srcIdx = path.rfind('src')
if srcIdx == -1:
# this is an egg package, strip down base path
basePath = path
moduleNames = pkgName.split('.')
moduleNames.reverse()
for mName in moduleNames:
mIdx = path.rfind(mName)
basePath = basePath[:mIdx]
pkgPath = path[len(basePath):]
else:
# this is a package linked in as externals
basePath = path[:srcIdx]
pkgPath = path[len(basePath):]
I don't understand why we need different code for packages
linked in as externals. The egg package code works
actually better for linked in packages that don't follow the
'src' convention.
Proposal: Use the 'if' code for all packages.
I was fighting several times with this part during coding.
The only thing which this part has to make sure is that
we do not use anything outside of the package in our path.
The reason for not including everything outside the package
in our path is that such a path whould be depend on the
local setup e.g.
D:\foo\dev\zope\session:3
We only have to make sure that this never will happen and that
we for each use case generate path like:
zope/session.py:3
It could be that the if part is working for all usecases.
but I'n not sure without debugging.
Debugging doesn't help much if we don't know all use cases.
What about testing it like this:
We remove the 'else' part and wait until someone complains. In that case
we have a scenario for testing and fixing the issue. If nobody
complains, the 'else' part was indeed useless.
The current code doesn't work for me because 'src' is found but not the
right place to split the path.
Cheers,
Yuppie
___
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] z3c.recipe.i18n and zope.app.locales.extract
Hi!
I plan to use z3c.recipe.i18n for some Zope 2 CMF products. But to get
things working I did have to modify z3c.recipe.i18n a bit.
It would be nice if I could get some feedback regarding the issues I found:
1.) running tests
-
test.py tries to install 'zodbcode' and 'zope.app.interface'. That
doesn't work for me. AFAICS those two eggs are no longer indirect
testing dependencies. After removing those two lines all tests pass.
Proposal: Remove those two lines in test.py.
2.) looking up the product version
--
POTMaker._getProductVersion() doesn't work for me.
zope.app.applicationcontrol is not used by Zope 2 and is not part of the
specified dependencies. This raises an error.
Proposal: Catch the error. Return an empty string if version is not found.
3.) customizing the .pot header
---
POTMaker.write() uses a harcoded Zope 3 specific pot_header template.
Proposal: The easiest and most flexible way to customize this seems to
be an option that allows to specify a file that contains the pot_header
template.
4.) looking up basePath
---
i18nextract.main() contains these lines:
# add maker for each given path
for pkgName, path in eggPaths:
srcIdx = path.rfind('src')
if srcIdx == -1:
# this is an egg package, strip down base path
basePath = path
moduleNames = pkgName.split('.')
moduleNames.reverse()
for mName in moduleNames:
mIdx = path.rfind(mName)
basePath = basePath[:mIdx]
pkgPath = path[len(basePath):]
else:
# this is a package linked in as externals
basePath = path[:srcIdx]
pkgPath = path[len(basePath):]
I don't understand why we need different code for packages linked in as
externals. The egg package code works actually better for linked in
packages that don't follow the 'src' convention.
Proposal: Use the 'if' code for all packages.
5. writing makers
-
I'd like to specify additional makers. This is a nice hook, but why are
only these three arguments passed to custom poMakers?
maker.add(poMaker(path, basePath, exclude_dirs), basePath)
I miss 'domain' and 'include_default_domain'.
Proposal: Pass in the additional arguments and fall back to the old
signature for BBB.
Does all that make sense? Any objections or better ideas?
Should changes for POTMaker go into zope.app.locales.extract or should
z3c.recipe.i18n use a customized version?
Cheers,
Yuppie
___
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] ZCatalog and indexes cleanup
Hi! I did plan to work on a small catalog improvement, but after looking at the code I'd like to do some cleanup first: 1.) remove the deprecated TextIndex The deprecation warning says: 'Using TextIndex is deprecated (will be removed in Zope ' '2.12). Use ZCTextIndex instead.' 2.) remove CHANGES.txt, README.txt and version.txt from Products/ZCatalog These files seem to be obsolete. 3.) remove security declarations from ZCTextIndex and DateRangeIndex All the other indexes don't have security declarations. AFAICS there is no way to access indexes from untrusted code without having the 'Manage ZCatalogIndex Entries' permission. 4.) add 'indexSize' to IPluggableIndex and implement it where missing ZCatalog uses that method and most indexes implement it already. If there are no objections, I'll make these changes on the 2.12 branch and the trunk. Cheers, Yuppie ___ 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] ZCatalog and indexes cleanup
Hi Andreas! Andreas Jung wrote: On 29.06.09 12:48, yuppie wrote: 3.) remove security declarations from ZCTextIndex and DateRangeIndex All the other indexes don't have security declarations. AFAICS there is no way to access indexes from untrusted code without having the 'Manage ZCatalogIndex Entries' permission. I think that all index implementation should have security assertions?! Why? '_catalog.indexes' is protected by the underscore and using the 'Indexes' alias is protected by 'Manage ZCatalogIndex Entries'. Only additional security restrictions would have any effect. Or am I missing a security hole? Cheers, Yuppie ___ 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] SVN: Products.GenericSetup/trunk/Products/GenericSetup/browser/addWithPresettings.pt - don't rely on manage_page_header, manage_form_title and manage_page_footer (in Zope 2.12 they can'
Tres Seaver wrote: Log message for revision 100073: - don't rely on manage_page_header, manage_form_title and manage_page_footer (in Zope 2.12 they can't be acquired) What? That can't be right: it will break *tons* of applications. Who did that? Sorry. That checkin message was too short: This is only the case if the context of the view is also a view. In all other cases they still work. Cheers, Yuppie ___ 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] [dev] five.localsitemanager: dependencies
Tres Seaver wrote: As I said earlier: five.localsitemanager should just be made part of the Zope2 trunk: it is tightly-coupled to Zope2, and its presence as a separate pacakge is just confusing and error-prone. +1 ___ 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: Eliminating Globals as an import façade
Tres Seaver wrote: svn+ssh://svn.zope.org/repos/main/Zope/branches/tseaver-no_globals_imports I would like to merge the branch soon, because it touches lots of files and is likely to hit conflicts if I let it go too long. +1 One tiny suggestion: Wouldn't it be better to add an alias in App.class_init instead of using from App.class_init import default__class_init__ as InitializeClass everywhere? Cheers, Yuppie ___ 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] Re: Extend specification of how to maintain the changelog
Hi! Second try. My first response to this lead to a discussion about immediate or delayed syncing of CHANGES.txt. That was not my point. Christian Theune wrote: On Wed, Jun 18, 2008 at 11:20:17AM -0400, Fred Drake wrote: On Wed, Jun 18, 2008 at 10:21 AM, Christophe Combelles [EMAIL PROTECTED] wrote: The risk is that people will think the bug is fixed in 3.6.0 and not in the 3.5 branch. That's a general documentation risk, and I don't think anyone else has come up with a better way to deal with this. If you can find an example that solves this without excess burden on the maintainers, that would be really good to hear about. The problem here is in managing the release notes in a single file within version control is easy to do. Everything else that makes this more clear either requires tedious manual tasks or really hard automation. Additionally, if you're bound to a branch, I guess it would be really easy to see what's changed there -- the release notes of that branch will tell you. The issue is that providing a 'correct' flat view of a tree structure is really hard in this case. The version numbering does not imply a time line! There is always *one* well defined current maintenance branch. Version numbering *does* imply a time line if you ignore old maintenance branches. It's not hard at all to get this right. Even when merging all the release notes, one would see the same change appear in 3.5.3, 3.6.4 and 3.7.0 eventually. Now, as you would read it from top to bottom, you might also think that it wasn't fixed in 3.5, even if you look there. You don't have to make things more complicated than they are right now. Nobody wants to merge release notes from old maintenance branches to newer branches. Changes on those branches are just backports. (Agreed, the lookup would be much simpler.) I think it is important to make it simple to look up what's new. I guess that merging release notes automatically would actually be easier in the format that I proposed ... I doubt that. In the format you propose the change note has to be placed in a different context. If we group changes on the trunk the same way as on the current maintenance branch, the context will always be the same. Cheers, Yuppie ___ 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] Re: Extend specification of how to maintain the changelog
Jens Vagelpohl wrote: On Jun 19, 2008, at 12:32 , yuppie wrote: There is always *one* well defined current maintenance branch. Version numbering *does* imply a time line if you ignore old maintenance branches. It's not hard at all to get this right. I don't think that assumption holds true. Again, using the CMF as an example, there were times when we had 3 release branches. I don't want to start a discussion why that was or how to prevent that from happening, I'm just saying it's not correct to say you always have just one maintenance branch. And that's where all those fancy schemes fall down. You did get me wrong :( I tried to make a distinction between the current maintenance branch (= branch for maintaining the *current* release) and old maintenance branches (= branches for maintaining older release). If someone knows better terms, please let me know. The *current* version of CMF is 2.1.1. If you release CMF 1.6.5 with some backports from the 2.1 branch, it will not become the *current* CMF release. As soon as CMF 2.2.0 is released it will become the current release and the 2.2 branch the current maintenance branch. No? Cheers, Yuppie ___ 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] Re: Extend specification of how to maintain the changelog
Jens Vagelpohl wrote: On Jun 19, 2008, at 13:36 , yuppie wrote: Jens Vagelpohl wrote: On Jun 19, 2008, at 12:32 , yuppie wrote: There is always *one* well defined current maintenance branch. Version numbering *does* imply a time line if you ignore old maintenance branches. It's not hard at all to get this right. I don't think that assumption holds true. Again, using the CMF as an example, there were times when we had 3 release branches. I don't want to start a discussion why that was or how to prevent that from happening, I'm just saying it's not correct to say you always have just one maintenance branch. And that's where all those fancy schemes fall down. You did get me wrong :( I tried to make a distinction between the current maintenance branch (= branch for maintaining the *current* release) and old maintenance branches (= branches for maintaining older release). If someone knows better terms, please let me know. The *current* version of CMF is 2.1.1. If you release CMF 1.6.5 with some backports from the 2.1 branch, it will not become the *current* CMF release. As soon as CMF 2.2.0 is released it will become the current release and the 2.2 branch the current maintenance branch. No? Sorry, you're right, I realized I did get you wrong after sending my reply. As always ;-) I do have one last question, though (unless I misunderstand something, again): In my understanding, we're now down to a single policy difference, about the point in time when you want the trunk CHANGES file updated. You're still saying it will only ever be fully updated when the current release branch changes are merged in, probably just before creating a new release branch, right? And you did get me wrong again ;) My first mail today started with these sentences: Second try. My first response to this lead to a discussion about immediate or delayed syncing of CHANGES.txt. That was not my point. I'm fine with keeping CHANGES.txt on the trunk always up to date. The policy difference I'd like to discuss is something completely different: How are the change notes grouped on the trunk? The proposed new policy is to put everything in one big section: Forward-ports from the current maintenance branch and trunk only changes are mixed together. CHANGES.txt just shows the difference between pre-releases of major versions. The old policy, which I like better in this point, solves this differently: Change notes for forward-ports are grouped by release versions from the current maintenance branch. CHANGES.txt helps you to figure out differences between any two versions in the series of 'current' versions, not only between major versions. Note that the policies are the same for CHANGES.txt files on all branches. They are only different for CHANGES.txt on the trunk. Cheers, Yuppie ___ 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] Re: Extend specification of how to maintain the changelog
Hi! Christian Theune wrote: On Wed, Jun 18, 2008 at 11:20:17AM -0400, Fred Drake wrote: On Wed, Jun 18, 2008 at 10:21 AM, Christophe Combelles [EMAIL PROTECTED] wrote: The risk is that people will think the bug is fixed in 3.6.0 and not in the 3.5 branch. That's a general documentation risk, and I don't think anyone else has come up with a better way to deal with this. If you can find an example that solves this without excess burden on the maintainers, that would be really good to hear about. The problem here is in managing the release notes in a single file within version control is easy to do. Everything else that makes this more clear either requires tedious manual tasks or really hard automation. Additionally, if you're bound to a branch, I guess it would be really easy to see what's changed there -- the release notes of that branch will tell you. The issue is that providing a 'correct' flat view of a tree structure is really hard in this case. The version numbering does not imply a time line! Even when merging all the release notes, one would see the same change appear in 3.5.3, 3.6.4 and 3.7.0 eventually. Now, as you would read it from top to bottom, you might also think that it wasn't fixed in 3.5, even if you look there. (Agreed, the lookup would be much simpler.) Why do we maintain a CHANGES.txt file? Who reads it and why? The audience I have in mind are users of released versions. They read CHANGES.txt to figure out what's new in a release. Let's take Zope 2 as an example: Most people will currently use version 2.10.6. If they read CHANGES.txt of Zope 2.11.0, they want to know what's new in 2.11.0 compared to 2.10.6. CHANGES.txt of Zope 2.11.0 is 233 lines long and provides (almost) exactly what they need. You propose to mix in all the change notes made between 2.10.0 and 2.10.6 with a total of another 240 lines. That makes it almost impossible to figure out what's new compared to 2.10.6. On the 2.10 branch we have the information which bugfix belongs to which 2.10 release. You just have to copy that information from the branch to the trunk. No big burden for the maintainers, but a big win for the users. Cheers, Yuppie ___ 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] Re: Extend specification of how to maintain the changelog
Jens Vagelpohl wrote: On Jun 18, 2008, at 19:00 , yuppie wrote: Why do we maintain a CHANGES.txt file? Who reads it and why? The audience I have in mind are users of released versions. They read CHANGES.txt to figure out what's new in a release. Let's take Zope 2 as an example: Most people will currently use version 2.10.6. If they read CHANGES.txt of Zope 2.11.0, they want to know what's new in 2.11.0 compared to 2.10.6. CHANGES.txt of Zope 2.11.0 is 233 lines long and provides (almost) exactly what they need. You propose to mix in all the change notes made between 2.10.0 and 2.10.6 with a total of another 240 lines. That makes it almost impossible to figure out what's new compared to 2.10.6. On the 2.10 branch we have the information which bugfix belongs to which 2.10 release. You just have to copy that information from the branch to the trunk. No big burden for the maintainers, but a big win for the users. That's not the only audience. I as a developer consult CHANGES.txt to (hopefully) find *all* changes on the respective branch or on the trunk that have flowed into it until now. Can't developers use the subversion history? I'm not sure what you're saying in that last paragraph. Copying a change history isn't needed when you're diligent about updating the change log whenever you make actual trunk changes. Sorry. I was referring to the current Zope 2 (and CMF) policy: Note that you don't need to note the fix in the CHANGES.txt on the trunk if you don't want to. At the time a new feature release is made, we merge the items in CHANGES.txt from the trunk and current release branch so that for any given release it notes the actual changes as of that release. http://www.zope.org/DevHome/Subversion/ZopeDevelopmentProcess Cheers, Yuppie ___ 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] Re: Extend specification of how to maintain the changelog
Hi! Jens Vagelpohl wrote: On Jun 18, 2008, at 19:27 , yuppie wrote: That's not the only audience. I as a developer consult CHANGES.txt to (hopefully) find *all* changes on the respective branch or on the trunk that have flowed into it until now. Can't developers use the subversion history? It's much quicker to look at the change log, and when you work with tarballs there's no subversion history. So no, that's not a good replacement for my uses. Nobody proposes to make releases without a complete CHANGES.txt. In a released version you should always find all changes. The only real difference between current and proposed policy is how the change notes are ordered and grouped. The current Zope 2 policy doesn't make sure the change history of unreleased versions is complete. But that's no essential part of that policy. And working with unreleased versions you might use subversion anyway. I'm not sure what you're saying in that last paragraph. Copying a change history isn't needed when you're diligent about updating the change log whenever you make actual trunk changes. Sorry. I was referring to the current Zope 2 (and CMF) policy: Note that you don't need to note the fix in the CHANGES.txt on the trunk if you don't want to. At the time a new feature release is made, we merge the items in CHANGES.txt from the trunk and current release branch so that for any given release it notes the actual changes as of that release. http://www.zope.org/DevHome/Subversion/ZopeDevelopmentProcess I think I have done some of that merging once in a while, but always in a haphazard fashion and did not know about the URL you provided. I personally dislike that, and would strongly favor noting every change on the trunk as it is checked in, just like you would do on the branch. Well. I don't like the if you don't want to part of the current policy because it just creates chaos. If everybody follows the same policy, the merging is not that much work. Cheers, Yuppie ___ 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] ZopeVocabularyRegistry
Hi! ZopeVocabularyRegistry allows to register vocabularies as utilities. _clear() in zope.app.schema.vocabulary hooks it up, importing zope.app.schema touches zope.app.schema.vocabulary and triggers the '_clear' call. Zope 2.10 did hook up ZopeVocabularyRegistry as a side effect of loading the deprecated vocabulary directive. http://svn.zope.org/?view=revrev=77097 removed the deprecated directive, breaking vocabulary registration. What is the recommended way to hook up ZopeVocabularyRegistry? Importing zope.app.schema.vocabulary in Five's __init__.py? Cheers, Yuppie ___ 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] coding style: using zapi recommended?
Hi! Products.Five.browser.adding is basically a copy of zope.app.container.browser.adding. Over time they became more out of sync than necessary. I'd like to fix that, but have one question: In the Five version from zope.app import zapi factory = zapi.getUtility(IFactory, type_name) was replaced by import zope.component factory = zope.component.getUtility(IFactory, type_name) (http://svn.zope.org/Products.Five/trunk/browser/adding.py?rev=67820r1=67728r2=67820) Was this a code modernization that should be ported to zope.app.container? Or should I revert the change in Products.Five? Keeping two different versions makes it unnecessarily hard to read the diffs. Personally, I prefer yet an other version: from zope.component import getUtility factory = getUtility(IFactory, type_name) But I don't want to change both files if there is no recommended version. Maybe we don't need a strict policy for this, but some guidance would be nice to have. Any opinions? Any guidelines I missed? Cheers, Yuppie ___ 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] Re: Interest in AdvancedQuery and/or ManagableIndex?
Hi Dieter! Dieter Maurer wrote: Whit (mailto:[EMAIL PROTECTED]) reported that AdvancedQuery is going to ship with Plone3 and that packaging would be easier for them if AdvancedQuery were part of the Zope 2 distribution. According to Whit, Alexander Limi seems to be interested to have Managable Index in the Zope 2 distribution, as well. I have no problems to donate AdvancedQuery and/or Managable Index to the Zope Foundation *BUT* I will not modify the code to bring it in line with the different style requirements usually applied to Zope components: e.g. * my code uses 2 blank indentation rather than the usual 4 blank (to make it more readable and easier to maintain for me) * I much prefer unit tests over doctests; thus, AdvancedQuery and Managable Index come with extensive unit tests and no doctests * I use camel case also for parameters and local variables and not only for functions and global objects. Is there interest in AdvancedQuery and/or Managable Index to become part of the Zope 2 distribution under these conditions? These seem to be mature products with a lot of valuable code and documentation. I think the Zope Foundation should count itself lucky to get a donation like that. Unfortunately integrating a product into the Zope core means more than just adjusting the coding style: - As already mentioned in this thread, monkey patches and code like fixPluginIndexes.py have to be resolved. AdvancedQuery contains a monkey patch for CMF - that should not be shipped with Zope core. - There should be one-- and preferably only one --obvious way to do it. Do we really need two different query methods in the catalog? Two different FieldIndexes, KeywordIndexes and PathIndexes in the core? Or is there a way to merge them or to deprecate one? - ManagableIndex seems to resolve some cataloging issues in the Zope 2 TTW way that are resolved in Zope 3 using adapters. Isn't that a step in the wrong direction? - Should we add new products to the core? I thought we want to move away from products and use python packages instead. The AdvancedQuery code might become part of the ZCatalog package, ManagableIndex might be converted to a non-products package. Of course this is just my opinion. These are no official rules. Cheers, Yuppie ___ 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] small catalog cleanup
Hi! Just want to make sure I'm not missing something: 1. IPluggableIndex -- Products.PluginIndexes.interfaces.IPluggableIndex has this method: def _apply_index(request, cid=''): Apply the index to query parameters given in 'request'. [...] Some implementations have an additional 'type' argument. Neither 'cid' nor 'type' are used anywhere in Zope core. The Catalog calls '_apply_index' just with the 'request' argument. That's the only place where '_apply_index' is used. Looks like 'cid' and 'type' can be safely removed from interface and implementations. 2. parseIndexRequest The 'get' method of Products.PluginIndexes.common.util.parseIndexRequest returns the default value if the value is not true. This changes values like 0 or False to the default value. Looks like a bug to me. But fixing this changes the behavior. If there are no objections, I'll resolve these two issues on the Zope trunk. Cheers, Yuppie ___ 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] Re: Zope 2.10.2 coming up
Hi! Philipp von Weitershausen wrote: yuppie wrote: The Zope 2.10 branch still uses Five 1.5.1. There are a few changes on the Five 1.5 branch (including a security fix) which should become part of Zope 2.10.2. I volunteer to resolve this as follows: Five releases are now linked tightly to specific Zope releases, so it doesn't make much sense to do still separate Five releases. See this thread: http://codespeak.net/pipermail/z3-five/2006q4/001889.html If there are no objections, I'll stitch the Five 1.5 branch HEAD directly into the Zope 2.10 branch (without using svn externals) and Five trunk HEAD into the Zope trunk. This would mean that from now on Five 1.5 and 1.6 are maintained as part of Zope 2. In fact there will be no Five 1.5.2 or 1.6 because there will no longer be any separate releases. Thoughts? + sys.maxint For the records: After some more off-list discussion with Philipp I decided to move only the trunk. This is done now. The 1.5 branch still exists and Philipp tagged Five 1.5.2 for Zope 2.10.2. Cheers, Yuppie ___ 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] Re: Zope 2.10.2 coming up
Hi! Andreas Jung wrote: I plan to release Zope 2.10.2 in a week or so (don't nail me to a particular date). The Zope 2.10 branch still uses Five 1.5.1. There are a few changes on the Five 1.5 branch (including a security fix) which should become part of Zope 2.10.2. I volunteer to resolve this as follows: Five releases are now linked tightly to specific Zope releases, so it doesn't make much sense to do still separate Five releases. See this thread: http://codespeak.net/pipermail/z3-five/2006q4/001889.html If there are no objections, I'll stitch the Five 1.5 branch HEAD directly into the Zope 2.10 branch (without using svn externals) and Five trunk HEAD into the Zope trunk. This would mean that from now on Five 1.5 and 1.6 are maintained as part of Zope 2. In fact there will be no Five 1.5.2 or 1.6 because there will no longer be any separate releases. Thoughts? Cheers, Yuppie ___ 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] Re: Zope Tests: 8 OK, 1 Failed
Hi! Andreas Jung wrote: --On 29. Oktober 2006 10:06:42 +0100 yuppie [EMAIL PROTECTED] wrote: Oops! Sorry! I did not mean to cause any confusion: - AFAICT the 2.10 branch points already to the 3.3.0 tag. Right. However Philipp pointed out that the Zope 2 trunk uses the Zope 3 trunk right now. I pointed the reasons for using the Zope 3 trunk in a former posting. I guess you mean 3.3 branch HEAD, not Zope 3 trunk HEAD. My argument for using the trunk instead of a fixed revision/tag is: when we develop against the trunk or implement something on the trunk then we want to be sure that the code also works with the latest Zope 3 changes. Otherwise something might break when we update the svn:exernals to latest Zope 3 changes at some time before an upcoming major release. So I would prefer that things break early than late. However as seen this approach has other side-effects..but I am open to let the svn:externals point to tags if you want that... Well. I would prefer if there would be somebody who volunteers to test Zope 2 every now and then with the latest Zope 3 revision. If he or she makes sure all tests pass, the svn:externals can be updated to that revision. In the long run the issues have to be resolved anyway, so doing this step by step would not be much extra work. And we could avoid to do big last minute changes right before the release. Pointing the svn:externals to the HEAD might encourage people to volunteer for fixing the issues, but I'm afraid a broken HEAD also discourages people to contribute other changes. Just my 2 cents. Cheers, Yuppie ___ 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] Re: Zope Tests: 8 OK, 1 Failed
Tres Seaver wrote: Test failures - Subject: FAILED (errors=1) : Zope-trunk Python-2.4.3 : Linux From: Zope Unit Tests Date: Mon Oct 23 21:35:18 EDT 2006 URL: http://mail.zope.org/pipermail/zope-tests/2006-October/006371.html First, thanks for resuming this collected report. I would much rather have links directly to the broken test run than to the buildbot page. Second, I can reproduce the failure on my machine, at least after an 'svn up' this morning, but have no obvious clue why it would be broken: the code for local site stuff in Five hasn't changed since May. The failure showed up after this checkin: http://svn.zope.org/?rev=70383view=rev But I didn't have time to track it down, so I opened this collector issue: http://www.zope.org/Collectors/Zope/2198 Cheers, Yuppie ___ 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] Re: You can always document...
Hi Chris! Chris Withers wrote: yuppie wrote: # Support old-style product metadata. Older products may # define attributes to name their permissions, meta_types, # constructors, etc. [followed by the code that interprets the 'methods' attribute] So 'methods' is BBB code for constructors. That depends on how you read the above. I'd say methods isn't deprecated ;-) (or, put differently, how do you provide functions needed by an add template? Squishdot has a need for this in obtaining a list of the available MailHosts) If these functions are only required by a specific template there is no need to add them to the global context. You can wrap the add form in a method and pass the functions (or better the result of the functions) as argument to the template. CMF's addConfiguredSiteForm does that e.g.: http://svn.zope.org/CMF/trunk/CMFDefault/factory.py?rev=68622view=auto If the container allows to use views (by default that is not the case for generic Folders in Zope 2.9) there is a better solution: Use a Five view and add the functions to your view class. The ZCML version of registerClass allows to specify a Five view as add form. Cheers, Yuppie ___ 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] Re: You can always document...
Hi Chris! Chris Withers wrote: yuppie wrote: I believe the Hippocratic Oath should be followed in subjective cases like this. First, do no harm. Cruft does harm. It discourages people who want to understand and improve Zope. And it encourages people to stick to bad coding habits. As far as methods goes, I call bullshit on this. Simple documentation of what methods is used for probably would have sufficed... This is how 'methods' is documented in OFS.Application:: # Look for an 'initialize' method in the product. If it does # not exist, then this is an old product that has never been # updated. In that case, we will analyze the product and # build up enough information to do initialization manually. [...] # Support old-style product metadata. Older products may # define attributes to name their permissions, meta_types, # constructors, etc. [followed by the code that interprets the 'methods' attribute] So 'methods' is BBB code for constructors. Other use cases might work, but they were never officially supported. Note that using 'methods' was already 'old-style' 6 years ago. Why do you want to have special support for monkey patching Folder? Which use cases justify to pollute the Folder API in that way? This is Zope 2, namespace polution is _not_ something that's going to get fixed... There were many attempts to fix this and the pollution would be much worse without those attempts. 'methods' was replaced by 'registerClass' to give constructors their own namespace: manage_addProduct. Cheers, Yuppie ___ 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] Re: OFS.Application deprecations for Zope 2.10
Hi Chris! Chris McDonough wrote: For what it's worth, maybe there's some middle ground here. Just because something is deprecated doesn't need it needs to have a hard date to be removed. Why don't we just have the first use of zLOG in each module generate a deprecation warning and just leave it there forever? People will get sick of seeing the warnings, and they'll eventually change it, but there's just no reason to *force* them to change it on our time schedule. And if they don't, who cares? People who don't want to see the warnings can filter them out. This sounds like a good compromise. At least for 'methods'. I don't know if we should leave it there forever, but we could keep it at least until it gets in the way of code improvements. Nobody complained about removing '__ac_permissions__' and 'meta_types' support, so I guess they can be removed in Zope 2.11. Cheers, Yuppie ___ 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] Re: Time-based releases a good idea?
Hi Chris! Chris McDonough wrote: On Wed, 2006-06-14 at 14:09 +0200, Wichert Akkerman wrote: No matter what period we decide on it will always be too short for some and too long for others. With the current setup the deprecation period is a year, which seems like a decent middle ground. A year suits me fine if it were the *actual* deprecation period, rather than the six-month deprecation cycle as is the case with zLOG and the eight-month deprecation cycle as is the case with 'methods'. As the person who added the deprecation warning for 'methods': If you calculate the deprecation cycle from the day the warning was added I agree it is too short. Reading the sources I had the impression that the fact there was no warning for the deprecated feature was a bug and I did consider my change a bugfix. Without warning it was already deprecated for many years. I'm fine with extending the deprecation period by one more release cycle. Cheers, Yuppie ___ 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] Re: Time-based releases a good idea?
Hi Chris! Chris McDonough wrote: On Jun 14, 2006, at 1:00 PM, yuppie wrote: It's not that simple. registerClass has an optional 'legacy' argument that does something quite similar. It just monkey patches ObjectManager instead of Folder. So at least for some use cases registerClass *will* help you. That would be helpful if I had a class to register. If I don't, it's an even worse hack than methods is. This is the case for External Editor. It has no addable types. And switching over to use something named legacy seems silly. How long until that's deprecated under the new clean-up-the-cruft-or-die regime? AFAICS the Right Way to modernize ZopeMailArchive and ExternalEditor would be using adapters. I don't recommend to abuse registerClass instead of 'methods'. And using a monkey patch is only the more obvious way of doing the wrong thing. I might be wrong, but it looks like the 'legacy' argument was added exactly for that one purpose: Providing a migration path for 'methods'. I doubt it was ever good practice to use 'methods' for something else than factory methods. Don't know how many products out there use 'methods' for something else. But so far the only product mentioned is ExternalEditor. PsycoPG-DA does, MySQLDA does, one of my products named ZopeMailArchive does. Even in the core ZClasses/__init__.py still uses it. And these are only the products I have on my hard disk. No idea how many others use it. The obsolete ZPsycopgDA 1.1 just uses it for factory methods, ZPsycopgDA 2.0 doesn't use it. The last ZMySQLDA release is 5 years old. It also uses it for factory methods. These 2 examples show that some very old products still use 'methods' instead of registerClass. They can easily be updated. ZClasses is no product and unless some other magic uses 'methods' it is ignored anyways. If adding deprecation warnings for 'methods' was a mistake it was not a simple mistake. I still believe it should be removed. I believe the Hippocratic Oath should be followed in subjective cases like this. First, do no harm. Cruft does harm. It discourages people who want to understand and improve Zope. And it encourages people to stick to bad coding habits. If we do deprecate it, we will need to have the deprecation warning *at least* say something better than use registerClass, because that's meaningless. Maybe it should give a URL that has content that explains how to monkey patch OFS.Folder. But in that case, it just seems dumb to deprecate; we know methods works. Maybe we can provide a utility method that does the same thing as 'methods' does? Why do you want to have special support for monkey patching Folder? Which use cases justify to pollute the Folder API in that way? You ignored my argument regarding the shorter deprecation period. But if there is a consensus that old deprecations without explicit deprecation message don't count I'm fine with extending the period for __ac_permissions__ and meta_types as well. I did not mean to ignore it, I thought I had acknowledged it in another mail, sorry. No problem. And meanwhile you answered this in another mail. While I still believe there was a good reason to differentiate between new and historical deprecations I now see that it is hard to communicate the difference and all the confusion it caused is not worth the shorter warning period. So I'm fine with starting new deprecation periods for all code that was deprecated the old way (not using warnings). Of course new deprecation periods have to start in a .0 release. Cheers, Yuppie ___ 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] Re: SVN: Zope/branches/ajung-zpt-end-game/...
Hi!
Tres Seaver wrote:
- CMFDefault/skin/configure.zcml blows up because the syntax of the
'browser:skin' directive has changed in a BBB-incompatible way. The
now-failing directive is::
browser:skin
name=cmf
layers=cmf default
/
and the traceback is *very* weird::
ZopeXMLConfigurationError: File \
/tmp/endgame/Products/CMFDefault/skin/configure.zcml, line \
10.2-13.8
ConfigurationError: ('Invalid value for', 'layers', ImportError:\
Couldn't import default, No module named default in cmf default)
Ah yes. This is due to a missing ZCML declaration in Five. I already
fixed it on the Five trunk
(http://mail.zope.org/pipermail/checkins/2006-May/001859.html), but the
zpt branch is a bit too old to have this fix. That's why it works fine
on the Zope trunk but not on the zpt branch.
They I guess we should update the external for Five on the branch, and
verify?
No, because Five was branched off too. But all that should be history
now, anyways, because I merged everything to the trunk and removed the
ZPT branches.
Those tests still break when run against the Zope trunk.
I can't confirm that. I no longer see the failures related to the
missing 'default' layer.
Most failures were caused by new requirements for the test setup and CMF
2.0 needs a backport of the test fixes on the CMF trunk.
So it all boils down to the empty expressions issue and this error:
Error in test test_allMetaTypes
(Products.CMFCore.tests.test_TypesTool.TypesTool
Tests)
Traceback (most recent call last):
File /usr/lib/python2.4/unittest.py, line 260, in run
testMethod()
File .../cmf21/Products/CMFCore/tests/test_TypesTool.py, line
114, in test_allMetaTypes
act = tool.unrestrictedTraverse(html_quote(factype['action']))
File /usr/local/lib/Zope-2.10/lib/python/OFS/Traversable.py, line
263, in un
restrictedTraverse
obj = next
UnboundLocalError: local variable 'next' referenced before assignment
Cheers,
Yuppie
___
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] Re: 2.10 branch and trunk
Hi! Tres Seaver wrote: Philipp von Weitershausen wrote: Andreas Jung wrote: I plan to create a branch for Zope 2.10 after 2.10beta 2 or short before the 2.10 final release. This means that the Zope trunk should only be used for bugfixes *only* until the branch is cut. So no new development and feature should happen on the trunk until then..Use your own branch until the trunk is open for new stuff to appear in Zope 2.11. I think we've had this discussion with Zope 2.9 already... I would prefer if we could make the branch now. +1. Our policy says[1]: At the time the first beta of the new feature release is made, we create a new branch for that feature release (rooted at the trunk at the time the first beta is made) I'll make the branch if no-one else has, via the following command line (using the later revision from which the actual release tag was cut):: $ svn cp -r 68385 $ZSVN/Zope/trunk $ZSVN/Zope/branches/2.10 [1] http://www.zope.org/DevHome/Subversion/ZopeDevelopmentProcess I would vote for a compromise: The branch should be created as soon as somebody wants to work on new features. As long as this is not the case the branch is just an extra burden and doesn't provide any benefits. Just my 2 cents. Cheers, Yuppie ___ 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] Re: 2.10 branch and trunk
Hi! Andreas Jung wrote: --On 30. Mai 2006 10:17:08 +0200 Andreas Jung [EMAIL PROTECTED] wrote: I plan to create a branch for Zope 2.10 after 2.10beta 2 or short before the 2.10 final release. This means that the Zope trunk should only be used for bugfixes *only* until the branch is cut. So no new development and feature should happen on the trunk until then..Use your own branch until the trunk is open for new stuff to appear in Zope 2.11. As Tres pointed out we do have a policy for branching so the 2.10 has been created. Feel free to mess up the trunk :-) http://svn.zope.org/Zope/branches/2.10/ Who made up that policy? And why? I don't think it's a good policy. It is very unlikely that people want to mess up the trunk right after the first beta. I'd prefer a policy like that:: After the first beta of the new feature release is made, we create a new branch for that feature release as soon as necessary (rooted at the trunk right before the first non-bugfix checked in). Cheers, Yuppie ___ 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] Re: SVN: Zope/branches/ajung-zpt-end-game/...
Hi!
Tres Seaver wrote:
yuppie wrote:
Tres Seaver wrote:
- CMFDefault/skin/configure.zcml blows up because the syntax of the
'browser:skin' directive has changed in a BBB-incompatible
way. The
now-failing directive is::
browser:skin
name=cmf
layers=cmf default
/
and the traceback is *very* weird::
ZopeXMLConfigurationError: File \
/tmp/endgame/Products/CMFDefault/skin/configure.zcml, line \
10.2-13.8
ConfigurationError: ('Invalid value for', 'layers',
ImportError:\
Couldn't import default, No module named default in cmf
default)
Ah yes. This is due to a missing ZCML declaration in Five. I already
fixed it on the Five trunk
(http://mail.zope.org/pipermail/checkins/2006-May/001859.html),
but the
zpt branch is a bit too old to have this fix. That's why it works
fine
on the Zope trunk but not on the zpt branch.
They I guess we should update the external for Five on the branch, and
verify?
No, because Five was branched off too. But all that should be history
now, anyways, because I merged everything to the trunk and removed the
ZPT branches.
Those tests still break when run against the Zope trunk.
I can't confirm that. I no longer see the failures related to the
missing 'default' layer.
Most failures were caused by new requirements for the test setup and CMF
2.0 needs a backport of the test fixes on the CMF trunk.
Are these the no traverser problems? Those are the ones I said were
still broken, and which Philip thought would have been fixed by the
newer Five version.
CMF 2.0 still exhibilts them, while the CMF trunk does not.
Yes. The 'no traverser' problems were not caused by the missing
'default' layer, so the Five fix doesn't resolve them. They are caused
by the fact that Five traversing is now used in more places, so more
tests need setUpTraversing/cleanUp.
So it all boils down to the empty expressions issue and this error:
I am planning to land my 'empty path expr BBB' patch on the trunk and
the 2.10 branch today.
I agree with you that there should be BBB code that provides the old
behavior and I agree with Philipp that not using that old behavior is a
benefit for the CMF.
Cheers,
Yuppie
___
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] Re: 2.10 branch and trunk
Tres Seaver wrote: yuppie wrote: Who made up that policy? And why? I don't think it's a good policy. It is very unlikely that people want to mess up the trunk right after the first beta. I'd prefer a policy like that:: After the first beta of the new feature release is made, we create a new branch for that feature release as soon as necessary (rooted at the trunk right before the first non-bugfix checked in). The purpose is to allow feature development for the next release to proceed without risking or interfering with the beta. The whole point of the release branch is to insulate the release process from such changes: it *is* the point where the release manager actually has the power to veto / release changes. The trunk is not really under the release manager's control. For a nice example of why *not* to freeze the trunk during a beta, have a look at the mess made during the ZopeX3 release cycle, where the trunk was feature frozen for *months* as an explicit act of policy (the RM was basically trying to coerce developers into fixing release critical bugs). Bugs which affect the release during the release cycle should be fixed on the release branch, and forward ported to the trunk if applicable. That is a slight amount of extra work, but well worth the reduction in the bottleneck on the trunk. You are arguing against a feature freeze policy for the trunk and I agree with you. But that is not what I propose. Often people don't *want* to check in new features for quite a while after the beta. And in that case I see the branch just as an unnecessary burden. Cheers, Yuppie ___ 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] Re: [ANN] pythonproducts 1.0beta1 released
Hi Rocky! Rocky Burt wrote: Well, pythonproducts patches regular Zope and also CMF. Five 1.4 includes the patches for regular Zope... and with Zope 2.10 those patches will of course be directly applied to Zope (thats what I'm working on right now). But there's still the matter of CMF. At some point I want to get the patches integrated into CMF 1.6 and/or 2.0 but with 1.6 its probably too late and with CMF 2.0 I need to better understand how the FTI stuff works before I can (or if I even should) apply the patches. This basically means with Zope 2.10, pythonproducts will be 75% useless ... everything besides the CMF stuff. listDefaultTypeInformation no longer exists in CMF 2.0 and AFAICS that's the only thing pythonproducts patches in CMF. So I guess 1.) the CMF stuff is obsolete with CMF 2.0 2.) pythonproducts doesn't work with CMF 2.0 (not tested, but patch_listDefaultTypeInformation seems to require listDefaultTypeInformation) 3.) registerPackage works out of the box with Five 1.4 / Zope 2.10 (also not tested) Cheers, Yuppie ___ 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] Re: What from zope.app are you using
Hi Philipp! Philipp von Weitershausen wrote: I would like to know what other zope.app packages your 3rd party software is using. If thereare any other used than the ones mentioned in the proposal, we'll have to move them out of zope.app. I'd like to ask for your help on that, otherwise future Zope 2 versions might not anymore include the package you're using. What are your plans for zope.app.locales? Five uses its translations. And CMF uses zope.app.locales.extract. Not in the CMF products, but for a script that extracts i18n messages. That script is a quick hack and zope.app.locales.extract isn't really made for reuse. But it contains some useful code. Cheers, Yuppie ___ 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] Re: What from zope.app are you using
Hi Philipp! Philipp von Weitershausen wrote: yuppie wrote: And CMF uses zope.app.locales.extract. Not in the CMF products, but for a script that extracts i18n messages. That script is a quick hack and zope.app.locales.extract isn't really made for reuse. But it contains some useful code. You're quite right. We should probably just move the whole zope.app.locales package. Perhaps to zope.translations? Perhaps it would also make sense to put the extractor and the ZCML directive handler for i18n:registerTranslations into zope.i18n and have zope.translations just contain the gettext files. Sounds good to me. At least if someone finds time to refactor the extractor. For now it is quite specific code for creating the zope gettext files and would better fit in zope.translations. Cheers, Yuppie ___ 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] Re: What from zope.app are you using
Philipp von Weitershausen wrote: yuppie wrote: Sounds good to me. At least if someone finds time to refactor the extractor. For now it is quite specific code for creating the zope gettext files and would better fit in zope.translations. On second thought, I think we should think about the zope.app.locales vs. zope.translation thing a bit harder. I don't think we should move it now. As for the extractor: it can very well be used for other projects than Zope 3. As you said, you guys are using it for the CMF. I would therefore still suggest moving it to zope.i18n. Yes. We are using it for CMF. But it was not fun to write the CMF code. Generally useful stuff is in utilities/i18nextract.py and zope specific stuff in zope.app.locales.extract. I did have to copy a lot from i18nextract.py and override many methods for changes that should be configurable. Extraction from ZCML still doesn't work. I don't want to blame anybody for that. Just say that the people who wrote it did not focus on writing reusable code. Cheers, Yuppie ___ 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 )
