Re: [Zope-CMF] DynamicType.portal_type
yuppie writes: > yuppie wrote: > > There is no test that shows what was broken and fixed. AFAICS there is > > nothing wrong with using None for uninitialized objects. We just have a > > new requirement in Products.ZCatalog 3: Attributes with None values can > > no longer be indexed. > > > > Wouldn't it be better to adjust the portal_type just for indexing in the > > IndexableObjectWrapper? > > Fixed the issue this way: > > - reverted r130422 > > - adjusted the IndexableObjectWrapper > > I guess other indexed attributes can also contain None. Not sure if > converting them to an empty string is always the best solution. Thanks for cleaning up after me. I took the easy way out when trying to make CMF trunk and Zope trunk work together. Adjusting the indexing behavior is the better approach. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Move to github?
yuppie writes: > Hanno Schlichting wrote: > > Does anyone have objections if I ask him to convert the CMF packages? > > Yes. I have objections. > > I'd like to keep contributing to CMF. But I'm not going to support > GitHub Inc. by using its services. Ok. I thought this might be controversial for CMF. I'm not going to push or argue about this for CMF, as I think Yvo is the closest to a benevolent dictator we have for CMF these days and the project certainly cannot afford to loose him. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] cmf-tests -
Patrick Gerken writes: > are the missing CMF Tests only temporary or is there a need for a new source of test reports? I spoke to Stefan Holek and he no longer has the time nor interest to maintain the Zope2 and CMF nightly tests. He's not working on any web based projects anymore, so this is quite understandable. As CMF isn't moving to github, it seems the free travis-ci integration won't help here either. So if someone is interested in running the tests, that would probably be appreciated. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] cmf-tests -
Maurits van Rees writes: > I have added a missing pin for z3c.recipe.scripts (1.0.1), which should > help there. I'm surprised you found that pin missing. I thought I had removed all use of that recipe from the CMF trunk builout, as it isn't compatible with buildout 2 yet. But maybe it's too ambitious to aim for buildout 2 / Zope 4 compatibility for CMF trunk. I only tried to fix the sources and buildout so it would at least run, after Zope was moved to github. But of course there's code and test changes to be made to reach compatibility with all the new zope.* 4.x versions. I'm not really up to work on all of those. So if nobody else is interested in that work, maybe it would be safer to aim for Zope 2.13 compatibility only at this point. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] cmf-tests -
Tres Seaver writes: > On 03/04/2013 06:46 AM, Maurits van Rees wrote: > > > If that commit helps, then some test errors will show up in > > Products.CMFDefault, mostly this: > > > > TypeError: Object has default comparison > > New BTrees expects objects used as keys to have "real" comparison > semantics: Python's default (based on id()) is not suitable for > persistent objects. The most common source of this warning is trying to store `None`: >>> from BTrees.OOBTree import OOBTree >>> tree = OOBTree() >>> tree[1] = 1 >>> tree[None] = 2 Traceback (most recent call last): File "", line 1, in TypeError: Object has default comparison Unfortunately the ZCatalog has advertised support for storing None for some time, so there's likely some code out there which uses this. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] Move to github?
Hi. Stephan Richter has volunteered to do SVN to Github conversions for all Zope projects and has already completed all of Zope 2 "core" and some actively used projects like five.localsitemanager. Does anyone have objections if I ask him to convert the CMF packages? And if Tres reads this: Objections to moving PAS / PluginRegistry? Cheers, Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Switching to Chameleon
On Wed, Sep 28, 2011 at 4:42 PM, Alan Runyan wrote: > but as Plone 4.3 probably would include CMF 2.3 Nah, it most likely won't. There's no PLIP yet to propose such an update and I'm not aware of anyone who plans one. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CatalogTool as utility
On Thu, Sep 22, 2011 at 3:14 PM, yuppie wrote: > My checkin for Products.ZCatalog has an optional dependency on > five.globalrequest. If five.globalrequest is not installed, > Products.ZCatalog behaves exactly as before. I hope we don't need a > Products.ZCatalog 2.14 release for that. Zope 2.13 can use it without > five.globalrequest. > > See http://svn.zope.org/?rev=122892&view=rev > > Is that ok? Should I add an explicit extra in the setup.py of > Products.ZCatalog? That's ok. One minor nitpick: Instead of writing: request = getattr(self, 'REQUEST', None) I'd write: request = aq_get(self, 'REQUEST', None) with a module import of: from Acquisition import aq_get That way objects which have only an explicit AQ chain or only __parent__ pointers will also work. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CatalogTool as utility
On Wed, Sep 21, 2011 at 1:57 PM, yuppie wrote: > I plan to use zope.globalrequest as fallback if self.REQUEST is not > available. > > What's the best approach for the five.globalrequest dependency? Just use > zope.globalrequest if it is available? Or specify it in extras_require? > Or add it to install_requires, making it an indirect dependency of the > next Zope 2.13 release? Adding it to the setup.py of what project? I consider using zope.globalrequest as a feature change - primarily because its interaction with tests is a bit unclear. Introducing more module global state for the request variable will probably lead to some changes to test isolation code somewhere. So in Zope itself, this can only go into trunk. For CMF 2.3, I'd just put it as a hard dependency into install_requires. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CatalogTool as utility
On Tue, Sep 20, 2011 at 12:19 PM, yuppie wrote: > But an additional ZCatalog branch is an additional maintenance burden. > And the required change is small and 100% backwards compatible. The > zope.globalrequest dependency could be made optional. > > Do we really need an extra ZCatalog branch for that? If there's a completely backwards compatible way of doing, we should do that. I was under the impression, that we had to do an API change for some methods and add a new request argument to those. If that argument is required depending on how the tool was retrieved, that's confusing to me and I'd rather go the zope.globalrequest route. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CatalogTool as utility
On Mon, Sep 19, 2011 at 3:56 PM, yuppie wrote: > But with zope.globalrequest we can avoid modifying the API. So if it is > fine to smuggle a zope.globalrequest dependency in Zope 2.13, that might > be the better solution. Or did you mean to use ZCatalog 2.14 only in CMF? I meant ZCatalog 2.14 only for CMF. Having independent distributions allows us to evolve them at a different pace :) Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CatalogTool as utility
On Mon, Sep 19, 2011 at 11:57 AM, yuppie wrote: > Is there a Plone branch > that is tested against CMF trunk? Their isn't a branch. Plone doesn't follow any moving targets from its lower stack. It always needs someone to sign-up for the job of updating and then dealing with all issues that the upgrade causes. Currently Plone most definitely won't pass all tests when run against CMF trunk - but it's unknown how much breakage there is. > Currently CMF trunk contains some hacks to work around the catalog brain > issues. But I hope there is a better solution. Maybe the ICatalogBrain > methods getURL, _unrestrictedGetObject and getObject should have a > REQUEST argument that is used instead of self.REQUEST? > > Any kind of feedback and help is welcome. Mmh, why don't we just use zope.globalrequest in ZCatalog directly? And create a new ZCatalog 2.14 release series with this. Then we don't have to wait for Zope 4.0 to include it. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] tools as utilities
On Mon, Sep 12, 2011 at 12:32 PM, yuppie wrote: > Jens Vagelpohl wrote: >> On Sep 12, 2011, at 11:52 , yuppie wrote: >>> I propose to use 'five.globalrequest' instead of self.REQUEST inside >>> tools. AFAICS that allows to convert *all* tools into utilities. +1 >> Why would you want to add a dependency for 3 lines of code? All that package >> does is register a 1 line event handler. I'd rather do that in the CMF >> itself. > > Because it provides an API that is also used and maintained by other > people. Plone 4.1 depends on it. I think we should just merge five.globalrequest into Zope2 itself. zope.globalrequest can stay on its own. This would be for Zope 4, in Zope 2.13 you would use the extra five.globalrequest package to enable this. >> IMHO the "cleaner" way would be to make sure the request object is >> explicitly passed into any code that needs it. > > Sure. But that requires either API changes in the tools or new view > code. The last 4 years nobody did work on this because it is much more > work than 'just' converting tools to utilities. Yep. I think changing the actual API's of all of these tools for the sake of better separation of concerns is not worth it anymore. We won't turn them into nice and pretty API's anyways as there's too few people working on this. So using the globalrequest "trick" sounds like the best approach to me. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] cmf-tests - OK: 3, UNKNOWN: 1
On Thu, Aug 11, 2011 at 9:31 PM, Jens Vagelpohl wrote: > On Aug 11, 2011, at 21:10 , Hanno Schlichting wrote: >> I tracked this down to a missing aq_inner call in the new >> getPhysicalPath and fixed that. > Thanks for taking the time, Hanno. I wouldn't have been able to figure than > one out. Any code that does manual __of__ wrapping is suspicious and suggests there's Acquisition problems lurking somewhere - I just got lucky to finding this one so fast ;) >> The "ValueError: 'Access contents information' not found in inherited >> permissions" failures remain, which are next on my list. That's "fixed" as well. The FS objects no longer have the "Access contents information" permission. They only got that through the OFS.ZDOM base class, which is gone in Zope 4. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] cmf-tests - OK: 3, UNKNOWN: 1
On Sun, Aug 7, 2011 at 5:13 PM, Jens Vagelpohl wrote: > After the wrapping, the discussion item has the wrong path. Even though > "self", the "talkback" object, has the correct path when calling > getPhysicalPath on it. I can't see anything overly stupid in the > DiscussionItem code, so there has to be an issue with that Zope > getPhysicalPath change. Reverting that one change in the current Zope trunk > fixes the tests. Thanks for the thorough analysis! I tracked this down to a missing aq_inner call in the new getPhysicalPath and fixed that. The "ValueError: 'Access contents information' not found in inherited permissions" failures remain, which are next on my list. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] cmf-tests - OK: 3, UNKNOWN: 1
On Sun, Aug 7, 2011 at 8:25 PM, Charlie Clark wrote: > Hanno, have you got any stats on the optimisation? I looked briefly at the > changes and I'm not sure if this is really worth it. Nikolay is working on this and some more evil looking patches at https://github.com/fafhrd91/experimental.performance These fixes combined currently result in almost a 50% speedup in rendering time and cut down the number of function calls significantly. Just one example he shared with me for rendering the edit screen of a page in Plone (req/s, function calls): Stock Plone 4.2: ~5.5, 17, /Plone/front-page/edit (manager) With Chameleon: ~7.8, 101000, /Plone/front-page/edit (manager) With evil looking optimizations: ~12.3, 43000, /Plone/front-page/edit (manager) So yes, while these changes look at bit evil, they do have a major impact. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] member data - a small proposal
On Thu, Jul 28, 2011 at 1:32 PM, yuppie wrote: > On CMF trunk I would like to > - add 'fullname' to that default list Sounds fine to me. Plone by default has the basic CMF ones, then fullname: and eight more. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] cmf-tests - OK: 3, UNKNOWN: 1
On Tue, Jul 5, 2011 at 12:44 PM, Charlie Clark wrote: > Am 05.07.2011, 07:00 Uhr, schrieb CMF tests summarizer : > >> [1] UNKNOWN FAILED (failures=1, errors=4) : CMF-trunk Zope-trunk >> Python-2.6.6 : Linux >> https://mail.zope.org/pipermail/cmf-tests/2011-July/014957.html > > All errors are related to FSMetaData > > Error in test test_basicPermissions > (Products.CMFCore.tests.test_FSMetadata.FSMetadata) > Traceback (most recent call last): > File "/usr/local/python2.6/lib/python2.6/unittest.py", line 279, in run > testMethod() > File > "/home/stefan/autotest/temp/python26-zope214-cmf23/src/Products.CMFCore/Products/CMFCore/tests/test_FSMetadata.py", > line 43, in test_basicPermissions > ['Manager','Anonymous']) > File > "/home/stefan/autotest/temp/python26-zope214-cmf23/src/Products.CMFCore/Products/CMFCore/tests/test_FSSecurity.py", > line 51, in _checkSettings > % permissionname) > ValueError: 'Access contents information' not found in inherited > permissions. Yes, these are my fault. I kept testing the CMF against Zope trunk for the most part of the weekend, but didn't run the tests anymore for the last round of changes. Not sure what exactly caused these, but I'll have a look. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup backport
On Tue, May 31, 2011 at 3:15 PM, Godefroid Chapelle wrote: > What I am actually trying to understand is which versions to give to > public releases after forking an existing branch. > > This is what dev releases are for (as you suggested). No. I said this is what private releases are for. > My proposal is then the following : I would publish a > Products.GenericSetup 1.4.6dev001 release from my backported branch to PyPi. Sorry, but publishing dev releases is frowned upon on PyPi. The version numbering scheme we have doesn't allow for you use-case. You want to effectively fork the 1.4 release series to continue with a different feature set than we have already gotten in the 1.5 and 1.6 series. We have a stable feature releases in all of the 1.4, 1.5 and 1.6 series. If you want to introduce any new feature you can only do this in the 1.6.x or 1.7 release series. Anything else means doing a private fork and publishing it under some other URL. It's really not that hard to do that and will only cost you ten minutes. Anyone who wants to use this version will need a find-links URL in addition to the version pin, but that's just one extra line of config. Doing this means keeping things sane and stable for the majority of users and adding a tiny little bit of extra work for the few that want to run your backport. I think that is a very sane approach. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup backport
On Thu, May 26, 2011 at 10:39 PM, Godefroid Chapelle wrote: > Le 26/05/11 17:15, Hanno Schlichting a écrit : >>> Smaller 1.4.x numbers could be kept for bug fix releases for CMF 2.1 and >>> Plone 3. >> >> That's a really weird way of doing it. And I'm a -1 on that. > > I agree it is a bit weird, I am just trying to be creative to comply with > your request of preserving Plone 3 tests. > > Outside being weird, can you explain issues you have ? You want to backport a feature that is known to break things into a stable release series. To me that's just wrong and defeats the very purpose of having stable releases. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup backport
On Thu, May 26, 2011 at 4:46 PM, Godefroid Chapelle wrote: > Would anyone see an issue that I release a Products.GenericSetup 1.4.20 > (or any other big integer) with ZCA registries ? > > Smaller 1.4.x numbers could be kept for bug fix releases for CMF 2.1 and > Plone 3. That's a really weird way of doing it. And I'm a -1 on that. Why don't you just cut a branch of GenericSetup 1.4 with your changes and make a private (vendor) release of it? Then put the private release up on some Web server serving a flat directory, including it into the buildout via find-links? We do that all the time, see for example http://dist.jarn.com/public/ Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Upgrade steps linked to profiles
On Tue, May 3, 2011 at 12:45 AM, Martin Aspeli wrote: > Several months ago, I seem to recall a discussion that led me to > believe it's now possible to register a GenericSetup upgrade step that > runs an extension profile when invoked, instead of having to write a > Python handler with imperative code to perform the migration. > > Now, I can't find any trace of this - was I imagining things? It's called "upgradeDepends" and you give it a import_profile and an explicit list of import_steps to run. It was introduced in GS 1.5 as: "Add ZCML tag; defines a specialized upgrade step that re-applies one or more import steps from a GS profile during an upgrade process" Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup backport
On Tue, Apr 26, 2011 at 11:53 AM, Godefroid Chapelle wrote: > I had made changes to GS registries (use ZCA instead of own registries) > which got released in 1.6.3. > > I backported those changes to 1.4. > > http://zope3.pov.lt/trac/browser/Products.GenericSetup/branches/1.4-with-global-zca > > Can I merge to 1.4 branch ? Please don't. The changes broke quite a number of tests and some of my own code. It's bad enough this got into the 1.6 bug fix releases, even though it's a feature change. Most tests failed as the ZCA now has to be setup before calling certain API's like "profile_registry.registerProfile". It's been a very common pattern in Plone add-ons to call this on the module level of a test to register a "test-only" profile. We have adjusted most of the test layers for the recent Plone release, so the change can stay in the 1.6.x series from my point of view. But if would be a lot of pain to do this for Plone 3.x releases using GenericSetup 1.4. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup: Question on StackOverflow
On Sat, Apr 9, 2011 at 11:31 AM, Jens Vagelpohl wrote: > IMHO it's not a metter of how popular a given tool is. It's a matter of > where the developers/supporters hang out and what channels they use for > accepting questions, bug reports or support requests. For the CMF that > means this list or the Launchpad sites for the various components. > > If there's someone who wants to volunteer monitoring and answering > requests on a separate channel, like that website, that's fine. But > until that time people should be warned that posting requests somewhere > else may not yield any results. Indeed. It just so happens that stackoverflow is the official support channel for Plone users as linked by http://plone.org/support For our casual users and integrators mailing lists aren't a good fit and using Nabble to mask mailing lists as web forums was only a minor improvement. We continue to use mailing lists for core and add-on developers. And of course it's up to the CMF developers to choose their official support channels. Just don't be alarmed if you see references to stackoverflow from time to time - it's probably from people coming through Plone. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup: Question on StackOverflow
On Sat, Apr 9, 2011 at 9:09 AM, Suresh V. wrote:
> http://stackoverflow.com/questions/5603459/genericsetup-what-does-toolset-xml-accomplish-if-toolinit-still-has-to-be-called
As Jens pointed out, the CMF developers don't use stackoverflow as a
support channel. But your question has been answered by the Plone
folks anyways.
As a side note: It's general considered bad practice to ask the same
question on multiple channels. This applies to posting the same
question to multiple mailing lists ("cross posting") or to a bug
tracker and a general mailing list or as in this case to a mailing
list and a web forum. At least wait a couple days to see if you get a
response on one channel, before posting it on a different one.
Hanno
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup global registries
On Wed, Mar 9, 2011 at 3:00 PM, Wichert Akkerman wrote: > You really want to use the ZCA for every occurance of a string->object > mapping? Really? As long as Zope doesn't have a central configuration registry like Pyramid has, it unfortunately makes sense. It's massive overkill and we shouldn't need to force simple values into interfaces, but that's the current state of things. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/trunk/Products/CMFCore/ Removed os.path.walk call in windows development mode
On Mon, Feb 7, 2011 at 2:59 PM, yuppie wrote: > If someone knows a better way to detect NTFS, please let me know. I looked for better ways, but there's nothing good in default Python or pywin32. The only real approach seems to involve calling the external diskpart command with a script like "list volumes" and parsing the output... nothing I'd want to do. And if I remember correctly diskpart isn't available on old Windows versions either. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/branches/2.2/Products/CMFCore/exportimport/content.py remove type check that seem useless
On Thu, Jan 13, 2011 at 2:17 PM, Godefroid Chapelle wrote: > You make me wonder if I am actually reproducing something wrong in my > tests setup : am I allowed to set a unicode value in Title and Description ? I'm not sure what the Unicode story is like for CMF. I'd expect there to be no conversion at any level, so whatever you set via a mutator is also what you get from the accessor. That means there could be both Unicode or encoded strings in the encoding as stored in the properties tool. In Plone the situation is a different. If you have Archetypes you can pass in either utf-8 or Unicode into mutator methods, it will internally always store Unicode and the accessor will always return utf-8. But if you have Dexterity you will only set Unicode and get Unicode from objects. Strings encoded in a different encoding than utf-8 aren't supported since Plone 3.0 - so the site_encoding value is meaningless here. So any code that uses mutators or sets attributes should use Unicode. Any code that gets values from accessor or direct attributes needs to handle both Unicode and utf-8 in Plone - in CMF it should also handle the additional arbitrary encoding set as site_encoding (which could be latin-1). There's more rules like all the data in one catalog index has to be in the same encoding or be all Unicode (or you'll get errors inside the BTree logic trying to compare mixed types). In Plone we changed page templates to except both utf-8 and Unicode inside TAL constructs and convert them to Unicode for you. In CMF that doesn't happen, so you need to be consistent. Unicode transition fun :) Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Zope-dev] SVN: five.pt/trunk/src/five/pt/ The container should be the Acquisition.aq_parent.
On Sun, Oct 24, 2010 at 2:29 PM, Tres Seaver wrote: > 'container' is supposed to be the folder which holds the script / > template, not the context. In a CMF site, that will typically be the > site root, given the way items in skin layers appear to be direct > attributes of the portal object. For purposes of Five views, the "view > object" seemss like the right object to be the 'container' for the > template: if that is the case here (hard to see from just the diff), great. Note this comment from Products.Five.browser.pagetemplatefile in the pt_getContext method (made during the AQ vs. parent pointer work): namespace.update( here=obj, # philiKON thinks container should be the view, # but BBB is more important than aesthetics. container=obj, ... So in view page templates container and context have historically always been the same. So far we said BBB trumps anything else here. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF dev buildouts
On Thu, Sep 23, 2010 at 12:38 PM, yuppie wrote: > If that concept works for everybody, I'll migrate the rest of the > CMF.buildout branches. +1, works for me as discussed in Dresden :) Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF vs. CMF.buildout
On Thu, Aug 5, 2010 at 3:07 PM, yuppie wrote: > I propose to merge CMF.buildout back into CMF and to delete CMF.buildout > in the long run. (Zope2.buildout did have a similar purpose and was > merged back into Zope.) +1 Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Test setup problems with Zope 2.13
On Wed, Jul 28, 2010 at 1:17 PM, yuppie wrote: > Hanno Schlichting wrote: >> ContentInit > > ContentInit is only used for BBB. It registers oldstyle constructors. Well, right. Except in Plone / Archetypes this and variants based on it are still the only option. Archetypes doesn't know about add views or any of that "new" IFactory pattern. >> I'd love to see someone tackle registerClass and at the same time >> decouple ZMI add menu visibility and the OFS.CopySupport stuff. > > You mean the CopySupport issue I fixed 5 years ago? Or something > different? http://svn.zope.org/?view=rev&rev=40552 > > five:registerClass doesn't require to specify an 'addview'. CopySupport > works for all CMF content types without adding them to the ZMI add menu. > > We just can't use five:registerClass in OFS/OFSP because it doesn't > support oldstyle constructors and legacy methods. Ah, yeah! This was exactly what I meant. I had no idea this was already done. So a belated thank you :) Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Test setup problems with Zope 2.13
Morning.
On Tue, Jul 27, 2010 at 1:09 PM, yuppie wrote:
> The whole registerPackage concept is a can of worms. We need real ZCML
> directives for *all* the stuff currently done in initialization
> functions. And to deprecate the usage of initialize instead of expanding
> that old concept to non-product packages.
Right. I think it's not all that many things left there.
Zope2 has:
registerClass
registerIcon
HelpSys (effectively deprecated)
CMF brings in:
ToolInit
ContentInit
I'd love to see someone tackle registerClass and at the same time
decouple ZMI add menu visibility and the OFS.CopySupport stuff. Well,
in general the CopySupport stuff could use some work and merging with
zope.copy / zope.copypastemove to correctly deal with persistent
parent pointers. But that's another story that also applies to the
ZEXP mechanism.
>> I reverted this now and all tests pass again. Both CMF 2.2 and CMF
>> trunk against Zope 2.13.
>
> I guess some more changes should be reverted. There is at least a
> ZopeTestCase.installPackage('OFS') in the FunctionalLayer of CMFCalendar.
I reverted the corresponding changeset and looked over my other
commits. I think that one was the only other change.
Hanno
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [GS] Running a setuphandler as first step
2010/7/27 Andreas Jung : > I have the requirement to execute my own setuphandler.py inside my own > profile before GenericSetup applies all other steps (*.xml) file. > Is there a way to configure this requirement somehow in import_steps.xml? import_steps.xml is deprecated, register the handlers in ZCML. Handlers registrations are global and not specific to a profile, so it didn't make sense to keep them inside a profile. You could maybe configure two profiles for your package. Have the first only do your custom step and depend on the second "real" profile via a dependency in metadata.xml. Maybe that works. Otherwise there's no explicit support for ordering a step before another step. Steps only have dependencies which cause them to execute after other steps. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Test setup problems with Zope 2.13
On Sat, Jul 24, 2010 at 3:26 PM, Hanno Schlichting wrote: > Hhm. This all looks like a can of worms to me. I think I'll still > revert my changes for 2.13 and see if I find the proper motivation to > fix this for 2.14 instead. I reverted this now and all tests pass again. Both CMF 2.2 and CMF trunk against Zope 2.13. Since I do want to use the CMF 2.2 + Zope 2.13 combination for Plone 4.1, I'd prefer that to be stable. I need to tell that to myself more often ;) Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 4 OK
Hi Stefan, it looks like we are missing some test runs. Could you have a look and make sure we also run: Trunk with Zope 2.13 svn://svn.zope.org/repos/main/CMF.buildout/trunk CMF 2.2 with Zope 2.13 svn://svn.zope.org/repos/main/CMF.buildout/branches/zope213-cmf22 Thanks, Hanno On Sat, Jul 24, 2010 at 1:58 PM, CMF Tests Summarizer wrote: > Summary of messages to the cmf-tests list. > Period Fri Jul 23 12:00:00 2010 UTC to Sat Jul 24 12:00:00 2010 UTC. > There were 4 messages: 4 from CMF Tests. > > > Tests passed OK > --- > > Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.6 : Linux > From: CMF Tests > Date: Fri Jul 23 21:51:13 EDT 2010 > URL: http://mail.zope.org/pipermail/cmf-tests/2010-July/013321.html > > Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.6 : Linux > From: CMF Tests > Date: Fri Jul 23 21:53:13 EDT 2010 > URL: http://mail.zope.org/pipermail/cmf-tests/2010-July/013322.html > > Subject: OK : CMF-2.2 Zope-2.12 Python-2.6.5 : Linux > From: CMF Tests > Date: Fri Jul 23 21:55:13 EDT 2010 > URL: http://mail.zope.org/pipermail/cmf-tests/2010-July/013323.html > > Subject: OK : CMF-trunk Zope-2.12 Python-2.6.5 : Linux > From: CMF Tests > Date: Fri Jul 23 21:57:13 EDT 2010 > URL: http://mail.zope.org/pipermail/cmf-tests/2010-July/013324.html ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Test setup problems with Zope 2.13
On Thu, Jul 22, 2010 at 2:00 PM, yuppie wrote: > yuppie wrote: >> +...@layer.onsetup >> def installPackage(name, quiet=0): >> '''Installs a registered Python package.''' > > Oops! > > For some unknown reason @layer.onsetup was explicitly removed here: > > http://svn.zope.org/?view=rev&rev=89898 Hhm. This all looks like a can of worms to me. I think I'll still revert my changes for 2.13 and see if I find the proper motivation to fix this for 2.14 instead. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Test setup problems with Zope 2.13
Hi.
Looks like nobody feels like jumping into the test layers waters.
Unless someone does in the next days, I'll revert the OFS / OFSP
refactoring on Zope trunk.
Hanno
On Sun, Jul 11, 2010 at 1:54 PM, Hanno Schlichting wrote:
> Maybe you have noticed from my commits today, but we have some test
> setup problems in Zope 2.13. I tried to solve those, but failed so
> far. Unfortunately we don't have nightly test runs for any CMF + Zope
> 2.13 combination for a while, so I'm not sure when all the problems
> started.
>
> One recent problem is due to my refactoring of Products.OFSP / OFS
> though. I moved the registrations of all standard OFS types from the
> initialize of OFSP into an initialize in OFS itself. In order for this
> to be picked up, I added the five:registerPackage statement, including
> a hint at the initialize function to OFS' configure.zcml.
>
> During normal Zope startup this works fine and the initialize is
> called. But we have a problem with ZopeTestCase based tests. So far it
> did an installProduct('OFSP') call unconditionally at module scope. As
> soon as someone imported it, the OFS types got registered. If the
> ZopeLite layer was active, the call was deferred to its layer setup
> time.
>
> In Zope 2.13 I removed the installProduct('OFSP') call, as it doesn't
> do anything anymore (apart from registering help system stuff which
> nobody needs in tests). But I cannot simply put an
> installPackage('OFS') in there as a replacement. In order for that to
> work, one needs to load the OFS.configure.zcml first (the
> five:registerPackage to be exact). Since ZopeTestCase doesn't know
> anything about ZCML setup so far, I don't want to introduce any such
> handling. Consumers of ZopeTestCase have all dealt with ZCML loading
> in various different ways and I expect even bigger problems when
> changing anything there.
>
> But this means any testcase that needs the OFS types (to show up in
> all_meta_types for example) will need to set up the ZCML and call
> installPackage itself. I tried to do this in CMFCore by adding a new
> layer, but cannot get it to work. There's always some side-effects in
> other tests. It doesn't help that installPackage internally does a
> transaction.commit() in 2.12 but not in 2.13.
>
> If anyone more familiar with the multitude of CMF test layers could
> help, that would be much appreciated.
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Test setup problems with Zope 2.13
On Sun, Jul 11, 2010 at 8:11 PM, Charlie Clark wrote: > thanks for patiently pointing out the obvious! I blame the heat. No problem. This happens rarely enough. I just happen to take apart Zope 2 at the moment :) > Affected are: Products.BTreeFolder2, Products.ExternalMethods, > Products.MIMETools, Products.OFSP, Products.PythonScripts, > Products.ZSQLMethods, Shared.DC.ZRDB And by now it's also zLOG and Products.StandardCacheManagers, more to come. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Test setup problems with Zope 2.13
Hi Charlie, On Sun, Jul 11, 2010 at 7:31 PM, Charlie Clark wrote: > 2010-07-11 19:23:38 ERROR Application Couldn't install BTreeFolder2 > Traceback (most recent call last): ... > stat_info = os.stat(path) > OSError: [Errno 2] No such file or directory: > '/Users/charlieclark/Sites/cmf-svn/CMF.buildout/trunk/src/Zope2/src/Products/BTreeFolder2/btreefolder2.gif' > > I see from the updates that Products/BTreeFolder2 has been deleted / > factored out. The question is - where's it gone to? Or what bits of my > buildout do I need to reinstall? When you work against an SVN checkout, please make sure to always run both SVN update and bin/buildout. Also check svn status for orphaned directories (those with a question mark) and delete them. Products.BTreeFolder2 doesn't live inside the Zope2/src tree anymore but is a standalone distribution. In Zope 2.13 this distribution is still a dependency of Zope2 and installed when running bin/buildout. Only in Zope 2.14 will it be a complete optional dependency. If you follow my above instructions, you should get a working buildout again. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] Test setup problems with Zope 2.13
Hi.
Maybe you have noticed from my commits today, but we have some test
setup problems in Zope 2.13. I tried to solve those, but failed so
far. Unfortunately we don't have nightly test runs for any CMF + Zope
2.13 combination for a while, so I'm not sure when all the problems
started.
One recent problem is due to my refactoring of Products.OFSP / OFS
though. I moved the registrations of all standard OFS types from the
initialize of OFSP into an initialize in OFS itself. In order for this
to be picked up, I added the five:registerPackage statement, including
a hint at the initialize function to OFS' configure.zcml.
During normal Zope startup this works fine and the initialize is
called. But we have a problem with ZopeTestCase based tests. So far it
did an installProduct('OFSP') call unconditionally at module scope. As
soon as someone imported it, the OFS types got registered. If the
ZopeLite layer was active, the call was deferred to its layer setup
time.
In Zope 2.13 I removed the installProduct('OFSP') call, as it doesn't
do anything anymore (apart from registering help system stuff which
nobody needs in tests). But I cannot simply put an
installPackage('OFS') in there as a replacement. In order for that to
work, one needs to load the OFS.configure.zcml first (the
five:registerPackage to be exact). Since ZopeTestCase doesn't know
anything about ZCML setup so far, I don't want to introduce any such
handling. Consumers of ZopeTestCase have all dealt with ZCML loading
in various different ways and I expect even bigger problems when
changing anything there.
But this means any testcase that needs the OFS types (to show up in
all_meta_types for example) will need to set up the ZCML and call
installPackage itself. I tried to do this in CMFCore by adding a new
layer, but cannot get it to work. There's always some side-effects in
other tests. It doesn't help that installPackage internally does a
transaction.commit() in 2.12 but not in 2.13.
If anyone more familiar with the multitude of CMF test layers could
help, that would be much appreciated.
Hanno
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2 releases
On Sun, Jul 4, 2010 at 11:30 AM, Jens Vagelpohl wrote: > As you may have seen from the checkins, I have done a CMF 2.2 point > release. Hanno said this would help Plone 4 testing. Thanks a lot! The new CMF releases should provide compatibility with Zope 2.13.0a1. So you should also be able to test CMF 2.2 against it :) Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] DirectoryViewSurrogate as context in FSPageTemplates
On Mon, Jun 28, 2010 at 1:00 AM, Enrique Perez wrote: > Though I would like some comment on the container variable issue: I > don't find changing it strictly necessary, at least for my use case, but > without changing the container I don't feel that the semantic > relationship between context and container remains quite right. I think the container variable should be changed as well. You probably don't see any problem as there's almost no code anywhere in Zope/CMF/Plone that actually uses it. Most code does its own aq_parent(context) calls. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Deprecation Error in CMFCalendar's tests
On Sat, Jun 26, 2010 at 8:37 PM, Charlie Clark wrote: > The only place I've noticed it triggering is the first time login/logout is > called. The error is actually raise by App/ClassFactory: > > /Users/charlieclark/Sites/cmf-svn/CMF.buildout/trunk/src/Zope2/src/Zope2/App/ClassFactory.py:23: > DeprecationWarning: UserFolder is deprecated. User folders are no longer > part of AccessControl, please depend on Zope2 and import from OFS.userfolder > or use the new minimal user folder classes from AccessControl.userfolder. > return getattr(m, name) > > Where m is AccessControl.User and name UserFolder Yes, it triggers once the /portal/acl_users folder is loaded from the database. > I can't find the corresponding call to that anywhere but I noticed some > other calls to AccessControl.User such as for nobody. Actually, there seem > to be quite a few nobodies around. Up to no good, no doubt! Most of AccessControl.User isn't deprecated. There's compatibility imports in that module taking care of everything else. I just had to move the code outside that module to avoid circular import problems. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Deprecation Error in CMFCalendar's tests
On Sat, Jun 26, 2010 at 7:50 PM, Charlie Clark wrote: > src/Products.CMFDefault/Products/CMFDefault/profiles/default/toolset.xml > > class="AccessControl.User.UserFolder"/> > > This can't be easily corrected without fixing the upgrade steps. Indeed. This will need an upgrade step and the registration needs to be conditional on the Zope version. Zope 2 itself takes care of the root acl_users folder and has inline migration code for that. In Plone's case all user folders are custom classes. I also looked at PAS and LDAPUserFolder which use custom classes as well. So none of these need special care, it's just anyone using the stock UserFolder class outside the root that needs to do some application specific migration. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] View permissions not triggering
On Sat, Jun 26, 2010 at 4:08 PM, Charlie Clark wrote: > No, I mean the permission set in the zcml view registration. As previously > discussed, I don't think "logged_in" and "logged_out" should be portal > actions as they are states. What exact zcml registration do you use? A browser:page or a browser:view directive? Browser pages should handle permissions just fine. Browser views don't support the permission attribute in Zope2 / Five. This feature has just never been implemented. See https://bugs.launchpad.net/zope2/+bug/578326 for a recent report. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Will the real test please step forward?
On Fri, Jun 25, 2010 at 8:30 PM, Charlie Clark wrote: > What are the guidelines on docstrings in unit tests? I'm finding it > helpful to write some kind of narrative which says what parameters are > being twiddled and what I expect as a result. Doesn't stop the contortions > with the method names but might help otherwise. We generally don't use docstrings in test methods. These will show up in the test output instead of the test method name and thus make it harder to find a failing test. Normal inline comments are perfectly fine and should be used it the tests intent isn't clear from the code. Most often the test code should be sufficient to explain itself or require some refactoring. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 2 OK, 3 Failed
This looks like its caused by Jens cleanup in Zope2: Error in test test_manage_propertiesForm_allows_adding (Products.CMFCore.tests.test_ActionInformation.ActionTests) Traceback (most recent call last): ... AttributeError: DummyRequest instance has no attribute 'URL1' Hanno On Wed, May 26, 2010 at 1:58 PM, CMF Tests Summarizer wrote: > Summary of messages to the cmf-tests list. > Period Tue May 25 12:00:00 2010 UTC to Wed May 26 12:00:00 2010 UTC. > There were 5 messages: 5 from CMF Tests. > > > Test failures > - > > Subject: FAILED (errors=1) : CMF-2.2 Zope-2.12 Python-2.6.5 : Linux > From: CMF Tests > Date: Tue May 25 21:48:17 EDT 2010 > URL: http://mail.zope.org/pipermail/cmf-tests/2010-May/013062.html > > Subject: FAILED (errors=1) : CMF-trunk Zope-2.12 Python-2.6.5 : Linux > From: CMF Tests > Date: Tue May 25 21:50:17 EDT 2010 > URL: http://mail.zope.org/pipermail/cmf-tests/2010-May/013063.html > > Subject: FAILED (errors=1) : CMF-trunk Zope-trunk Python-2.6.5 : Linux > From: CMF Tests > Date: Tue May 25 21:52:17 EDT 2010 > URL: http://mail.zope.org/pipermail/cmf-tests/2010-May/013064.html ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: CMF.buildout/trunk/src/ Don't use http:// externals for CMF externals.
On Thu, Apr 1, 2010 at 5:39 PM, Tres Seaver wrote: > I'm +0 on making this change: I don't konw who will be using this > buildout via an anonymous HTTP URL, but if everybody working on CMF is > alraedy using SVN >= 1.5, I can't see any harm in the relative externals. I've gone ahead and made the change. One obvious user that doesn't handle svn+ssh urls is the nightly buildbot. So using relative externals seems to be the best option. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: CMF.buildout/trunk/src/ Don't use http:// externals for CMF externals.
On Thu, Apr 1, 2010 at 1:24 PM, yuppie wrote: > Jens Vagelpohl wrote: >> Bringing up that question again certainly doesn't do any harm. I >> personally have no objections to using relative SVN URLs. > > I don't plan to bring it up again on Zope-dev. I just proposed to make > an exception for CMF. I'm on Subversion 1.6 anyways, so +1 for using the new format for the CMF buildout. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed
On Wed, Mar 31, 2010 at 8:33 PM, Tres Seaver wrote: > OK, the change I'm planning on the trunk essentially reverts your last > commit (all the extra version pins to make the 'test-zope212' part > build), plus deleting the test-zope212 part (see attached patch). Sure. That wasn't much more than a band-aid. > BTW, I think the other test buildouts which do not run aganst the Zope2 > trunk should probably also be adjusted to use released Zope 2.12.x eggs > as well: we aren't co-developing the Zope 2.12 branch along with CMF > 2.2 (any more, at least). Well, it is nice to catch problems introduced in Zope 2 on the day after they are made. And not when someone tries to update the buildout to a new version at some later point. The risk is much lower for stable branches, but it still exists. As seen from todays test failures, they nicely showed how I screwed some things up a bit too much on Zope trunk :) > I also don't know why the 'instance' and 'i18n*' parts are configured in > these buildouts -- does somebody have a memory of why, or a reason to > keep them? Yvo has to comment this. I think he sometimes rebuilds the pot files in CMF with the i18n part. Not sure about the instance. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed
2010/3/31 Tres Seaver :
> I believe the root of this problem is that the 'index' and 'versions'
> bits of a buildout.cfg are effectively Highlanders ("there can only be
> one"). I gave up on trying to get the "two, two, two Zopes in one"
> buildout to work, and instead created a separate buildout.cfg for
> running CMF's tests against Zope 2.12.3.
Yeah, that sounds sensible. The extra test part with an index was a
hack in the first place.
> Unless somebody objects violently, I plan to check the attached config
> in on a branch of the main CMF buildout, and rip out the stuff which
> tries to do both from the trunk version. This change will require
> Stefan's nightly runner to be adjusted, so I'm CC'ing him.
Looks all good, except for this first line of comment, which should be
CMF trunk + Zope 2.12 :)
> # CMF trunk + Zope trunk
Personally I prefer versions.cfg files, so we could use an:
extends = http://download.zope.org/Zope2/index/2.12.3/versions.cfg
instead of the index = line. But I don't care much for this specific
test buildout.
> [buildout]
> parts =
> zopepy
> test
> eggs =
> Zope2
> Products.CMFCalendar
> Products.CMFCore [test]
> Products.CMFDefault
> Products.CMFTopic
> Products.CMFUid
> Products.DCWorkflow
> Products.GenericSetup
> five.localsitemanager
> develop =
> src/Products.CMFCalendar
> src/Products.CMFCore
> src/Products.CMFDefault
> src/Products.CMFTopic
> src/Products.CMFUid
> src/Products.DCWorkflow
> src/Products.GenericSetup
> src/five.localsitemanager
> index = http://download.zope.org/Zope2/index/2.12.3
>
> [versions]
> # CMF-only dependencies
> five.formlib = 1.0.2
>
> [zopepy]
> recipe = zc.recipe.egg
> eggs = ${buildout:eggs}
> interpreter = zopepy
> scripts = zopepy
>
> [test]
> recipe = zc.recipe.testrunner
> eggs = ${buildout:eggs}
> defaults = ['--module', '^Products[.](CMF|DC|GenericSetup)|^five[.]']
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [GS] Execution order of steps (import handler executed before tool creation)
Hi. 2010/1/23 Andreas Jung : > I am currently in trouble with the imports of a particular Plone > product (CMFBibliographyAT). I'm pretty sure I've helped Martin to fix this in a branch for CMFBibliographyAT. Martin, did you check in your work from the last Tune-Up? What happened there, was an error earlier up in the GS steps (look up in the log), which prevented the tool from being created. But maybe this is also something new. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Problem with offline buildout
On Thu, Jan 21, 2010 at 9:44 AM, Charlie Clark wrote: > It would be nice if that was the case but I get the same problem on OS X: > > """ > We have no distributions for Products.CMFCore that satisfies > 'Products.CMFCore'. > Getting distribution for 'Products.CMFCore'. > Running easy_install: > /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python > "-c" "from setuptools.command.easy_install import main; main()" "-mUNxd" > "/Users/charlieclark/Sites/zurich/eggs/tmpegx0OT" "-q" > "/Users/charlieclark/Sites/zurich/downloads/dist/Products.CMFCore-2.2.0.tar.gz" > path=/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages > > Download error: [Errno 8] nodename nor servname provided, or not known -- > Some packages may not be found! > Couldn't find index page for 'eggtestinfo' (maybe misspelled?) > """ > > setuptools wants to check something online even thought it has everything > it needs. This is an entirely unrelated issue to the one you had on Windows. In this case the CMF packages all have the following in their setup.py: setup_requires=['eggtestinfo',], It seems setup requirements (compared to the usual install requirements) aren't put into the buildout download cache. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Problem with offline buildout
On Wed, Jan 20, 2010 at 2:56 PM, Charlie Clark wrote: > I'm testing deploying a current project using buildout's offline mode. I > have a complete download cache but I'm still getting errors: > > "We have no distributions for products.cmfcore that satisfies > 'products.cmfcore'." I think you've run into a Windows specific problem with case-sensitivity. The requirement should be called "Products.CMFCore", which would also be in the download cache. But something is turning that into an all lower-case "products.cmfcore". I suspect that the filesystem might not be case-sensitive and something does an os.listdir call or similar. I've seen the same behavior of all-lowercase names on my Windows 7 test machine. I'd suspect it's not just a single place but quite a number of them that are affected by this. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup and PluggableAuthService
On Wed, Dec 30, 2009 at 4:19 PM, Jens Vagelpohl wrote:
> In the debugger I see that the object in question is a absolute_url
> adapter residing in the base component registry in the site root. IMHO
> the components exporter should not look at the base registry at all,
> only a local registry if one exists in the folder the tool sits in. Correct?
Right. As you noticed nobody ever tried to use GS outside a CMF/Plone context :)
The code in question does a:
sm = getSiteManager(context.getSite())
That will get the nearest site manager, which in case of CMF will
always be the one in the CMF site root.
What you want is probably something like this:
from zope.component.interfaces import ComponentLookupError
from zope.component.interfaces import IComponentRegistry
from zope.location.interfaces import IPossibleSite
def importComponentRegistry(context):
"""Import local components.
"""
# context is the portal_setup tool
# getSite is GS API to get the parent
site = context.getSite()
sm = None
if IPossibleSite.providedBy(site):
# All object managers are an IPossibleSite, but this
# defines the getSiteManager method to be available
try:
sm = site.getSiteManager()
except ComponentLookupError:
sm = None
if sm is None or not IComponentRegistry.providedBy(sm):
logger = context.getLogger('componentregistry')
logger.info("Can not register components, as no registry was found.")
return
importer = queryMultiAdapter((sm, context), IBody)
if importer:
body = context.readDataFile('componentregistry.xml')
if body is not None:
importer.body = body
And then adjust exportComponentRegistry in a similar way. This is
untested code :)
Hanno
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Checkins] SVN: Products.CMFCore/trunk/ - fixed Zope 2.12 compatibility
On Sun, Dec 27, 2009 at 8:31 PM, Jens Vagelpohl wrote: > Please keep release scheduling in mind. I had announced a release date > for CMF 2.2.0-final about a week from now. Andreas cannot possible throw > out Zope 2 2.12.3-final by that time. We would need to postpone CMF > 2.2.0-final for any of this to happen. Ok. Here's a deal: I made CMF trunk and the 2.2 branch use five.formlib in favor of Products.Five.formlib, including a fallback to Products.Five. So at this point everything works with both Zope 2.12 / 2.13. You can now go ahead and make a CMF 2.2 final release whenever you like. Next I'll backport the five.formlib work to Zope 2.12. Once that is done and a 2.12.3 is released, we can change CMF trunk to require five.formlib and add a minimum requirement onto 2.12.3. At this point we can drop the fallback to Products.Five on CMF trunk. Anything I overlooked? Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Checkins] SVN: Products.CMFCore/trunk/ - fixed Zope 2.12 compatibility
On Sun, Dec 27, 2009 at 5:45 PM, yuppie wrote: > Hanno Schlichting wrote: >> Just to make this explicit: CMF trunk should continue to run with Zope >> 2.12 and not only with 2.13, correct? > > Yes. At least until there is an explicit decision to drop 2.12 > compatibility. So far I can't see a good reason for dropping BBB. Ok. Makes sense. >> On a related note, if I'm going to backport the five.formlib >> extraction to 2.12, it would it be ok to depend on a 2.12.3 release >> for CMF 2.2 with this stuff in it, right? > > I can live with dropping support for Zope 2.12.2 if 2.12.3 is released. > It's always recommended to use the latest bugfix release of Zope. > > On the other hand we would just need a few try except imports to keep BBB. Indeed. There's not too many places that deal with formlib. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Checkins] SVN: Products.CMFCore/trunk/ - fixed Zope 2.12 compatibility
Hi. On Sat, Dec 26, 2009 at 6:25 PM, Yvo Schubbe wrote: > Log message for revision 107108: > - fixed Zope 2.12 compatibility Just to make this explicit: CMF trunk should continue to run with Zope 2.12 and not only with 2.13, correct? If so, I'll add a second test runner to the buildout, so it's easier to ensure this. On a related note, if I'm going to backport the five.formlib extraction to 2.12, it would it be ok to depend on a 2.12.3 release for CMF 2.2 with this stuff in it, right? Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 3 OK, 1 Unknown
On Fri, Dec 18, 2009 at 6:16 PM, Tres Seaver wrote: > Hanno Schlichting wrote: >> Right. Zope2 has finally lost a lot of transitive dependencies. I'll >> make sure CMF actually declares those itself. > > We should just get the CMF trunk to import from the new, correct locations. I just did that for the zope.app.publication vs. zope.traversing change. The testing dependency on zope.app.testing in CMFCore is more involved. I declared it for now to get the tests running again. Help in refactoring the tests to get rid of it, would be welcome ;) Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 3 OK, 1 Unknown
On Fri, Dec 18, 2009 at 1:39 PM, Jens Vagelpohl wrote: >> URL: http://mail.zope.org/pipermail/cmf-tests/2009-December/012382.html > > @Hanno: These are all import problems, probably connected to your > current reshuffling of Zope2 dependencies? Right. Zope2 has finally lost a lot of transitive dependencies. I'll make sure CMF actually declares those itself. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF and Zope trunk
On Tue, Nov 17, 2009 at 4:00 PM, Charlie Clark wrote: > Yes, I'm fine with that - how do I fix it? I can then tie my buildout out > CMF 2.2 beta or release. My buildout.cfg is exactly the same as the > CMF-sandbox with just my modules being added. I just noticed that we already have an appropriate branch / buildout at http://svn.zope.org/repos/main/CMF.buildout/branches/zope212-cmf22/ You might want to use that one. But you probably don't need Zope2 from SVN but can use the latest release. You can extend the versions file from http://download.zope.org/Zope2/index/2.12.1/versions.cfg for Zope 2.12.1. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF and Zope trunk
Hi. On Tue, Nov 17, 2009 at 3:34 PM, Charlie Clark wrote: > working on my first CMF-based buildout and I'm getting an error in > CMFCore.DynamicType > > from zope.app.publisher.browser import queryDefaultViewName > ImportError: No module named publisher.browser > > My buildout is almost exactly the same as the CMF sandbox but I can see > that I have zope.app.publis...@3.9.0 in the sandbox but > zope.app.publis...@3.10.0 in my new buildout - both have been freshly > updated and bootstrapped. So you are working against Zope 2.13 (trunk) instead of Zope 2.12 (branches/2.12). Zope 2.13 already has a couple of more changes due to the whole Zope Toolkit refactoring. I guess for now running CMF trunk (2.2) against Zope 2.12 would be more reasonable. Once there's a 2.2 beta and branches for it, CMF trunk can start tracking Zope trunk again. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2.0-alpha: getIcon
Hi. On Mon, Nov 16, 2009 at 6:24 PM, yuppie wrote: > CMF 2.2.0-alpha has some getIcon changes based on what I proposed here: > https://mail.zope.org/pipermail/zope-cmf/2009-January/028059.html > > Unfortunately the issue is more complicated than I thought and some > things are now broken in CMF 2.2.0-alpha: The return values of getIcon() > and icon() are not backwards compatible, breaking e.g. the ZMI icons if > REQUEST['BASEPATH1'] exists. > > There are 4 ways to specify icons: Oh dear :-( > Proposal > > > In CMF we always need the absolute URL. Since getIcon() and icon() > already have a different meaning and something like > getIcon(absolute=True) looks too complicated for the default, I propose > to add a new method: getIconURL() > > getIcon() and icon() should get the same behavior as they had in CMF 2.1. Sounds reasonable. I was hoping we could get away with a new method but it seems I failed. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup: comparing version numbers
Hi. On Mon, Nov 16, 2009 at 6:07 PM, Maurits van Rees wrote: > In the metadata.xml in your profile the best practice is currently to > use plain version numbers, right? So just 1, then 2, then 3 etc and > not 1.0 then 1.1 then 1.2, right? Yes. > Using plain version numbers I have just hit a problem that I find > strange that I have not hit before. An upgrade step from 8 to 9 went > fine. Then I did an upgrade step from 9 to 10 and suddenly > portal_setup listed theprevious upgrade step as available, since '10' > was alphabetically smaller than '9'... > > As a workaround I added one or more zeroes to the source, destination > and metadata.xml version numbers and then it works. I will hit the > next problem after the 99th upgrade step. ;-) > > Should we change this in GenericSetup itself and add some zeroes in > front when comparing numbers? Which version of GenericSetup was this? In the upcoming 1.5 (Plone 4.0) the code uses the pkg_resources API to parse version numbers instead of interpreting them as simple strings. That should cover your use-case. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Releasing GenericSetup 1.5.0b1
Heya. On Thu, Sep 24, 2009 at 6:02 PM, Tres Seaver wrote: > hanno wrote: >> I was planning to refactor some of the Acquisition wrapping code, now >> that Acquisition supports parent pointers. >> >> I'd still like to do that before we get a 2.0 final out. I can try to >> put that up on my priority list and get over with it sometime next >> week. > > If you could, that would be great: five.lsm is the bottom of a pretty > big food-chain of pending releases (five.lsm 2.0 <- GS 1.5.0 <- CMF 2.2 > <- Plone 4.0). five.lsm 2.0 final is released and up on PyPi - let the release fest begin ;) Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [GS] u'Existing registration for step various, version 20090619-01'
2009/9/19 Andreas Jung : > The related profiles with this version are: > > NormenDB/profiles/default/import_steps.xml: version="20090619-01" > Toolbox/profiles/default/import_steps.xml: version="20090619-01" > > Although making the version attrs unique did not help (even with > creating a complete > new CMF site). > > Is there anything missing or what is the approach for hunting this down? The id of an import step needs to be globally unique. Having two steps with the id "various" is not supported. Steps don't belong to a profile, which is clearer if you register them via ZCML. The whole import_steps.xml file is deprecated. The version argument dance has never been used by anyone as far as I know and could just as well be removed. Hanno ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
