[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] makeClass and makeClassForTemplate
Hi Laurence! Laurence Rowe wrote: Now that you've cleaned up Products.Five in Zope trunk, what should other packages that use ``makeClass`` and ``makeClassForTemplate`` change to? Well. I wasn't aware of the fact that other packages use these constructors. Please let me know if you think additional BBB support is needed. For five.formlib I simply exchanged ``makeClass`` for ``type`` and ``makeClassForTemplate`` for ``SimpleViewClass``, see: http://zope3.pov.lt/trac/changeset/127697/five.formlib/branches/zope-trunk-compat Would these changes be ok for packages that want to continue working with Zope 2.13? AFAICS it's fine to use the ``type`` constructor instead of ``makeClass`` in Zope 2.13. ``SimpleViewClass`` is not available in Zope 2.13, so that part will not work in Zope 2.13. ``makeClassForTemplate`` has a slightly different signature, but the way five.formlib uses it should work with both versions. So I would fall back to ``makeClassForTemplate`` if import of ``SimpleViewClass`` doesn't work. HTH, 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 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 )
Re: [Zope-dev] Zope trunk: browser views
Charlie Clark wrote: Am 10.07.2012, 16:29 Uhr, schrieb yuppie : 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 )
[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-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=123141&view=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=121808&view=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 Seaver: [...] >>> [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%2Ftrunk&old=121746%40zopetoolkit%2Ftrunk > Oops! My mistake. Hope this is fixed now: http://svn.zope.org/?rev=121787&view=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=)
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 - 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 )
Re: [Zope-dev] ZPublisher: using zope.formlib and z3c.form in Zope 2
Charlie Clark wrote: > Am 04.03.2011, 08:58 Uhr, schrieb yuppie: > >> 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
Hi! Laurence Rowe wrote: > On 2 March 2011 11:29, yuppie wrote: >> Laurence Rowe wrote: >>> On 2 March 2011 10:00, yuppiewrote: >>>> 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
Hi Charlie! Charlie Clark wrote: > Am 02.03.2011, 12:29 Uhr, schrieb yuppie: > >> 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] ZPublisher: using zope.formlib and z3c.form in Zope 2
Laurence Rowe wrote: > On 2 March 2011 10:00, yuppie wrote: >> 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. 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=115280&view=log http://svn.zope.org/plone.z3cform/trunk/plone/z3cform/z2.py?rev=109071&view=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 )
[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] 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, in > 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 )
Re: [Zope-dev] Zope 2: specifying Zope2 dependency
Hi! Hanno Schlichting wrote: > On Tue, Jan 4, 2011 at 2:53 PM, yuppie 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 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 )
[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 Tests: 42 OK, 8 Failed
Hi! Patrick Gerken wrote: > On Thu, Oct 7, 2010 at 10:50, Wichert Akkerman 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 )
Re: [Zope-dev] unit test policy questions
Hi! Marius Gedminas wrote: >> And if I use the -t option (-ttest_tool), most tests fail :( > > That is an indication that the tests aren't independent. I would > consider such a test suite to be broken. Well. In this case the tests are independent from each other, but not from the way tests are filtered: The -m filter is applied *before* test modules are imported. The -t filter is applied *after* importing all available test modules. Some nasty code in Zope 2 behaves differently if different modules are imported before running the tests. 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! Hanno Schlichting wrote: > On Thu, Jul 29, 2010 at 2:23 PM, Martin Aspeli > wrote: >> On 29 July 2010 20:14, yuppie wrote: >>> 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. :) > > Don't forget -m which runs exactly one module (file). > > I always use commands like: > > bin/test -s zope.package > bin/test -s zope.package -m test_module > bin/test -s zope.package -m test_module -t test_some_method If everybody is using this, nobody is using CMF.buildout for development. Anyway. I fixed CMF.buildout: http://svn.zope.org/?rev=115204&view=rev > Especially since unittest and zope.testing can even discover > TestSuites inside modules, it seems any kind of explicit configuration > in the test files isn't needed anymore. Do you think it should become policy to remove "def test_suite():" where possible? I'm not sure if I like that because it is less explicit. 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, yuppie 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] 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 )
[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] "Comply with repository policy" ?
Hi! Christian Theune wrote: > On 04/09/2010 05:31 PM, yuppie wrote: >> 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. > > Right. I'd consider that behaviour not a bug, but actually point out > that all the examples in documentations that I have found considered the > copyright to be stand-alone on a single line with the next line > following to carry the "All rights reserved" remark. Although the tool > screws up, the output of the tool really is intended to be reviewed by > the person who does the checkin. I doubt looking at "examples in documentations" was the best approach. The tool modifies code, not documentation. Most headers in the Zope 2 world look different. They did have "All Rights Reserved." in the same line and now they are without that remark. >> 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 > > I'd move this off from the topic of the tool being broken: if either of > you would like to follow up on removing the "all rights reserved" from > the header, then please acknowledge that and I'll pick it up (probably > that needs to go to the foundation?!? I bet some lawyer wanted that > phrase to be in there originally and I guess we have to ask the ZF board > whether that part of the policy can be changed.) I don't think it is important if "All Rights Reserved." is part of the header or not, see http://en.wikipedia.org/wiki/All_rights_reserved But I think it is important to have a policy how the headers should look like. A policy accepted by everybody. Obviously the ZTK docs currently don't fulfill that role. It would reduce noise (pointless diffs) and make sure we don't waste time with rivaling cleanups. Automated header updates would also be easier. 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'
> 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=97&view=rev
And I hope together with the change in HTTPResponse your issue is
resolved now:
http://svn.zope.org/?rev=99&view=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: > 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:
> Unauthorised is doing stupid things here:
>
> (Pdb) p v
> Unauthorized()
> (Pdb) p unicode(v)
> u''
> (Pdb) p str(v)
> *** UnicodeEncodeError: UnicodeEncodeError('ascii',
>u'
> 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:
> 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 = '' % 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 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] 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] 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=110801&view=rev http://svn.zope.org/?rev=110806&view=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=rev&rev=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=rev&rev=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=92767&view=diff&r1=92767&r2=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: > 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] "Comply with repository policy" ?
Hi! Tres Seaver wrote: > o Run the automated fixups:: > > $ /path/to/zrp/bin/zope-org-fix-project . > ... ... 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] [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 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-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 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! Hanno Schlichting wrote: > On Sun, Dec 27, 2009 at 5:43 PM, yuppie 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 )
[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! 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 )
Re: [Zope-dev] z3c.recipe.i18n tests fail
Christian Zagrodnick wrote: > On 2009-12-01 16:36:50 +0100, yuppie 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.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] 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=104817&view=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] 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=85827&view=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=102515&view=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=102009&r1=101795&r2=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=102515&view=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=102009&r1=101795&r2=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=102230&view=rev http://svn.zope.org/?rev=102231&view=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: >>>> 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=101958&view=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! >> 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: >> 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,
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 )
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 )
[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] 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
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
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
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
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] 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! 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] 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=rev&rev=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=67820&r1=67728&r2=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 )
Re: [Zope-dev] Re: Zope Tests: 8 OK, 1 Failed
Hi Andreas! Hi Philipp! Andreas Jung wrote: --On 28. Oktober 2006 23:50:36 +0200 Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: OMG, why are we using the 3.3 branch HEAD on the 2.10 branch??? This is how Stephan's fix got pulled into Zope 2 automatically and *automatically broke* Zope 2. It also broke Five trunk for some reason (the formlib stuff). Obviously, this is bad. We should stick to specific revisions or tags when pointing to externals. Pointing to HEAD of a branch or trunk is insane as it's an uncontrollable risk. As discussed with you: I will change the externals on the 2.10 branch to the related 3.3 tag. Oops! Sorry! I did not mean to cause any confusion: - AFAICT the 2.10 branch points already to the 3.3.0 tag. - The test failure is on Zope trunk which points to the 3.3 branch HEAD. - The collector issue I opened mentions an unsupported combination (Zope 2.10 branch with Five trunk and Zope 3.3 branch). I hope there will be a Zope 3.3.1 release that will be included in Zope 2.10.1. The person who will stitch in the Zope 3.3.1 tag will see this failure and http://www.zope.org/Collectors/Zope/2198 might give a hint what the problem is. 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=70383&view=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=68622&view=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: 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: 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: 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: Time-based releases a good idea?
Hi Chris! Chris McDonough wrote: On Wed, 2006-06-14 at 15:42 +0200, yuppie wrote: 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. That is the case for meta_types and __ac_permissions__ but I think you mistook the fact that "methods" followed a comment that said "handle old-style product data" for the fact that it was deprecated. But it never was officially deprecated, nor did it ever need to be. It just *happened* to follow that comment, lumped in with meta_types and __ac_permissions__. The deprecation warning is nonsensical there. "please use registerClass instead" is a non-sequitur as a deprecation warning, because registerClass will not help you do what "methods" does. 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. 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. BTW: The name and comments in the code of the 'legacy' argument make clear that using these legacy methods is deprecated as well. I'm fine with extending the deprecation period by one more release cycle. That's fine for __ac_permissions__ and meta_types, but can't we just leave 'methods' in? IMO, deprecating it was a simple mistake, and that's OK. We don't need to make another mistake by actually removing it for the sake of being consistent with the earlier mistake. If adding deprecation warnings for 'methods' was a mistake it was not a simple mistake. I still believe it should be removed. 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. 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: OFS.Application deprecations for Zope 2.10
Hi Chris! Chris McDonough wrote: Jusst out of curiosity, what is the rationale for deprecating "methods"? It has been deprecated for at least 6 years now, I just added the warnings last year. I don't know the old discussions, but the comments added here make pretty clear that initialize() was meant to replace '__ac_permissions__', 'meta_types' and 'methods': http://svn.zope.org/Zope/trunk/lib/python/OFS/Application.py?r1=18170&r2=18185 I guess 'methods' was never meant to be used for something else than factory methods. As Florent already pointed out using it for general monkey patching doesn't look like a good idea. We only can improve the product initialization if we first remove some cruft. 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 )
