[Zope-dev] Re: [Zope-Checkins] CVS: Products/PluginIndexes/common - UnIndex.py:1.20.2.7
Tres Seaver wrote: +if set is None: +set = IISet(()) +elif type(set) is IntType: # isinstance(set, int) for 2.8 How come isinstance is only to be used for 2.8? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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-Checkins] CVS: Products/PluginIndexes/common- UnIndex.py:1.20.2.7
Chris Withers wrote: Tres Seaver wrote: +if set is None: +set = IISet(()) +elif type(set) is IntType: # isinstance(set, int) for 2.8 How come isinstance is only to be used for 2.8? Hi, when I wrote the patch and the test case I tried to be consistent with the actual code. On 2.7 the check was done with type() while on 2.8 with isinstance(), so I added a comment. Probably I should have stated this in the collector entry. Regards -- (@ @) oOO(_)OOo-- Ojo por ojo y el mundo acabara ciego /\ Alexis Roda - Universitat Rovira i Virgili - Reus, Tarragona (Spain) --- ___ 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: mechanism for license boilerplate?
On May 30, 2005, at 20:39, Chad Whitacre wrote: Thanks, that's what I figured. ;-) IIRC the last time I did something like that (moving CMF to ZPL 2.1) I wrote a python script to replace the text appropriately... sed and awk are also good tools for that when you're good at shell scripting. jens ___ 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] mechanism for license boilerplate?
On May 30, 2005, at 3:06 PM, Andreas Jung wrote: --On 30. Mai 2005 12:35:22 -0400 Chad Whitacre [EMAIL PROTECTED] wrote: Dear all, I am wondering what mechanism the Zope team uses to manage the copyright/license boilerplate at the top of every file. Is this handled manually or is it automated? Cut Paste :-) If you include Zope 3, Zope 3 has utilities/headerfix.py. Haven't used it in a long time, if ever, but it might be worth a look if you want something automated. Gary ___ 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: CMFSetup + ZopeTestCase interaction bug
On 5/25/05, Lennart Regebro [EMAIL PROTECTED] wrote: When you use the installProduct command of ZopeTestCase on a product that has a CMFSetup profile you may get the following error: File /home/zopes/27test/Products/CMFSetup/registry.py, line 567, in registerProfile raise KeyError, 'Duplicate profile ID: %s' % profile_id KeyError: 'Duplicate profile ID: profile id' This typically happens on the profile CMFDefault:default. This also *only* happens if you try to run all tests in Products. The reason seem to be that all or some of the products gets installed by Zope. When you then try to install them again with installProduct, you get the error. My suggested solution is to merge ZopeTestCases list of installed products with Zopes list of installed products, as these for the moment are not the same, as far as I can see. I discussed this with Stefan Holek yesterday, and today I tried this solution, and it seems to work fine. This error happens both with Zope2.7 and 2.8. But...I suggest that I only change this in Zope 2.8 anyway, to make sure we don't break anything that relies on this ZopeTestCase behaviour. Unless somebody screams, I will include this bugfix in 2.8 today or tomorrow. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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-Checkins] SVN: Zope/trunk/ - Collector #1323: applied patch to fix umask problem in zdctl
[Andreas Jung] Log message for revision 30558: - Collector #1323: applied patch to fix umask problem in zdctl Changed: U Zope/trunk/doc/CHANGES.txt U Zope/trunk/lib/python/zdaemon/zdctl.py Andreas, Zope doesn't own zdaemon. zdaemon is (so far) *copied* into Zope from repos/main/zdaemon/trunk/. Checkins made to a zdaemon copy from a client project (like Zope) have no effect on the zdaemon code. So, for example, the zdaemon trunk is still broken, the zdaemon copies in Zope3 and in ZODB are still broken, and the changes you checked in to Zope's copy are likely to get lost the next time someone copies zdaemon into Zope. The right way to fix this in Zope is: 1. Apply the patch to repos/main/zdaemon/trunk/. 2. Make a tag of zdaemon trunk. 3. Delete (svn rm) Zope's copy of zdaemon and commit. 4. From a Zope checkout, svn propedit svn:externals lib/python, and add a line naming the zdaemon tag you created in step #2. That would make zdaemon like Zope's other external code (the ZopeX3 stuff, assorted ZODB directories, and ZConfig), and the existence of a zdaemon tag (there isn't one now) would make it easy for other projects (like Zope3 and ZODB) to use the _same_ zdaemon code. ___ 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-Checkins] SVN: Zope/trunk/ - Collector #1323: applied patch to fix umask problem in zdctl
[Andreas Jung] I thought Fred hooked zdaemon and ZConfig already as external definition. But apparently this happened only for ZConfig. That's correct; nothing about zdaemon has changed yet. Back on 13 May: [me] The first time ZConfig and zdaemon get tagged, it's important that whoever do that first search all clients (ZODB and both Zopes) for changes to those checked in from a wrong project, and do merges back to ZConfig and zdaemon (I explained that dance last time) -- else those changes (if any) will get lost. [you] That's a job for loosers :-) but I will take it over for ZConfig and ZDaemon.. maybe not for the next beta but hopefully for the final for 2.8.1 release. so I thought you would be doing this. Fred fixed a bug in ZConfig since then, and did the right thing to get it fixed everywhere. The same hasn't been done for zdaemon yet, and I'm sure Fred won't be doing it. If it *had* been done already, SVN would not have allowed you to check in a change to zdaemon made from Zope, forcing you to make the change in the right place (i.e., in zdaemon) instead. ___ 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 )
