Re: [Zope3-dev] z3c.formjs-0.2 and z3c.formjsdemo-0.2 released!
Hi Paul, Hey, very smooth. Congratulations. I've committed a change to buildout.cfg removing z3c.form* develop eggs which kinda spoilt the buildout. Best regards, Darryl Cousins ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Problems with ZODB3-3.9.0_dev_r77011
Hi, zope.app.keyreference-3.5.0_dev_r77018-py2.4.egg requires ZODB3=3.9.0-dev-r77011 But there might be a caching problem within ZODB3-3.9.0 dev r77011, my debug session tells: /development/Zope3/MyProject/eggs/ZODB3-3.9.0_dev_r77011-py2.4- macosx-10.4-ppc.egg/ZODB/Connection.py(644)_store_objects() - raise (Pdb) obj zope.app.file.image.Image object at 0x3faadb0 (Pdb) oid '\x00\x00\x00\x00\x00\x00\x00\xc6' (Pdb) self._cache[oid] *** KeyError: '\x00\x00\x00\x00\x00\x00\x00\xc6' (Pdb) self._cache[oid] = obj *** TypeError: Cache values must be persistent objects. But zope.app.file.image.Image should be persistent. (Pdb) dir (obj) ['__annotations__', '__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__', '__getstate__', '__hash__', '__implemented__', '__init__', '__module__', '__new__', '__providedBy__', '__provides__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setstate__', '__slotnames__', '__str__', '__weakref__', '_data', '_getData', '_height', '_p_activate', '_p_changed', '_p_deactivate', '_p_delattr', '_p_getattr', '_p_invalidate', '_p_jar', '_p_mtime', '_p_oid', '_p_serial', '_p_setattr', '_p_state', '_setData', '_size', '_width', 'contentType', 'data', 'getImageSize', 'getSize'] Looking forward to some hints or help, Tobias ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: Problems with zope3 on windows
Hi Hanno -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Hanno Schlichting [...] Full tracebacks are available in the thread from May/June at http://mail.zope.org/pipermail/zope3-dev/2007-June/022752.html The problem is still that zc.zope3recipes uses zopectl and in turn zdaemon which don't work on Windows. As outlined in the old thread this is a known problem and not that hard to fix. Right it uses zdaemon which doens't fit for windows. Currently it justs needs someone to sit down and do the work. I myself won't do it, as I only use Zope 3 through Zope 2 where all this has already been fixed ;) Can you point me to the right repos/place of this allready fixed issue in Zope2. So I can take a look at that and fix it if I find out how this eggs work. Regards Roger Ineichen Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Problems with zope3 on windows
João Paulo Fernandes Farias wrote: Steps to reproduce: Thanks. I'm sure this information will help whomever works on this issue. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [ZODB-Dev] Problems with ZODB3-3.9.0_dev_r77011
On Jul 19, 2007, at 7:11 AM, Tobias Rodäbel wrote: Hi, zope.app.keyreference-3.5.0_dev_r77018-py2.4.egg requires ZODB3=3.9.0-dev-r77011 But there might be a caching problem within ZODB3-3.9.0 dev r77011, my debug session tells: /development/Zope3/MyProject/eggs/ZODB3-3.9.0_dev_r77011-py2.4- macosx-10.4-ppc.egg/ZODB/Connection.py(644)_store_objects() - raise (Pdb) obj zope.app.file.image.Image object at 0x3faadb0 (Pdb) oid '\x00\x00\x00\x00\x00\x00\x00\xc6' (Pdb) self._cache[oid] *** KeyError: '\x00\x00\x00\x00\x00\x00\x00\xc6' (Pdb) self._cache[oid] = obj *** TypeError: Cache values must be persistent objects. But zope.app.file.image.Image should be persistent. (Pdb) dir (obj) ['__annotations__', '__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__', '__getstate__', '__hash__', '__implemented__', '__init__', '__module__', '__new__', '__providedBy__', '__provides__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setstate__', '__slotnames__', '__str__', '__weakref__', '_data', '_getData', '_height', '_p_activate', '_p_changed', '_p_deactivate', '_p_delattr', '_p_getattr', '_p_invalidate', '_p_jar', '_p_mtime', '_p_oid', '_p_serial', '_p_setattr', '_p_state', '_setData', '_size', '_width', 'contentType', 'data', 'getImageSize', 'getSize'] Looking forward to some hints or help, Hi Tobias. The ZODB 3.9 dev version is only different from 3.8 in some conflict resolution code, for which I am responsible. Some thoughts. - I haven't seen any errors like this yet. That's just a data point, and certainly does not necessarily invalidate your report. - Is this consistently reproduceable, or intermittent? Unless you are intentionally creating a conflict in a test, any errors in the changes in 3.9 would be more likely to be intermittent. - Even better, can you construct a small, distributable test case? That would certainly invite more help. - Have you tried to reproduce with the most recent zope.app.keyreference in the 3.4 line and the most recent ZODB 3.8 line? If so, that might get Jim's attention, and would rule out the relatively small changes in the 3.9 dev egg. Unless you like riding the bleeding edge, I might suggest using those earlier versions for now anyway. Gary___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: AW: Re: Problems with zope3 on windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roger Ineichen wrote: -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Hanno Schlichting [...] Full tracebacks are available in the thread from May/June at http://mail.zope.org/pipermail/zope3-dev/2007-June/022752.html The problem is still that zc.zope3recipes uses zopectl and in turn zdaemon which don't work on Windows. As outlined in the old thread this is a known problem and not that hard to fix. Right it uses zdaemon which doens't fit for windows. Currently it justs needs someone to sit down and do the work. I myself won't do it, as I only use Zope 3 through Zope 2 where all this has already been fixed ;) Can you point me to the right repos/place of this allready fixed issue in Zope2. So I can take a look at that and fix it if I find out how this eggs work. http://svn.zope.org/Zope/?rev=75066view=rev Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn3aV+gerLs4ltQ4RAorJAKC+ha97jGbjdQsALG4s0WcTg10fjgCdHKvz SVXpo3mHa8tXoWt/UL1+Z5k= =9t6d -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Re: [ZODB-Dev] Problems with ZODB3-3.9.0_dev_r77011
Hi Tobias Auftrag von Gary Poster Gesendet: Donnerstag, 19. Juli 2007 15:53 An: Tobias Rodäbel [...] zope.app.keyreference-3.5.0_dev_r77018-py2.4.egg requires ZODB3=3.9.0-dev-r77011 But there might be a caching problem within ZODB3-3.9.0 dev r77011, my debug session tells: /development/Zope3/MyProject/eggs/ZODB3-3.9.0_dev_r77011-py2.4- macosx-10.4-ppc.egg/ZODB/Connection.py(644)_store_objects() - raise (Pdb) obj zope.app.file.image.Image object at 0x3faadb0 (Pdb) oid '\x00\x00\x00\x00\x00\x00\x00\xc6' (Pdb) self._cache[oid] *** KeyError: '\x00\x00\x00\x00\x00\x00\x00\xc6' (Pdb) self._cache[oid] = obj *** TypeError: Cache values must be persistent objects. But zope.app.file.image.Image should be persistent. [...] Looking forward to some hints or help, Hi Tobias. The ZODB 3.9 dev version is only different from 3.8 in some conflict resolution code, for which I am responsible. Some thoughts. I'm pretty shure you ve got a LocationProxy arround your object because the zope.app.file doesn't implement ILocation. I've had this issue too and removed the location before I stored the object.With e.g. @apply def photo(): See interfaces.IPersonalData def get(self): photo = self._photo if zope.proxy.isProxy(photo): photo = zope.proxy.getProxiedObject(photo) if photo is not None: proxy = LocationProxy(photo) proxy.__name__ = 'photo' proxy.__parent__ = self return proxy def set(self, photo): if photo is not None: # remove location proxy because the ZODB doesn't like it anymore photo = zope.proxy.getProxiedObject(photo) self._photo = photo return property(get, set) Note: This sample only works in our project because the name is allways ``photo``. Gary - This happens because of the call in ZODB.Connection.py $Id: Connection.py 75693 2007-05-11 22:18:37Z jim $ cool that we have the revision info in the file header ;-) line: 627 except: # Dang, I bet it's wrapped: # TODO: Deprecate, then remove, this. if hasattr(obj, 'aq_base'): self._cache[oid] = obj.aq_base else: raise My question is, can we improve the method: if hasattr(obj, 'aq_base') and remove the proxy with a method that works? Tobias -- Can you agree this? And probably tell us if the obj is a proxy? You can check this by get the type of the object. e.g. type(obj) Regards Roger Ineichen Gary___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: [Zope3-dev] Re: [ZODB-Dev] Problems with ZODB3-3.9.0_dev_r77011
On Jul 19, 2007, at 10:36 AM, Roger Ineichen wrote:
Hi Tobias
Auftrag von Gary Poster
Gesendet: Donnerstag, 19. Juli 2007 15:53
An: Tobias Rodäbel
[...]
zope.app.keyreference-3.5.0_dev_r77018-py2.4.egg requires
ZODB3=3.9.0-dev-r77011
But there might be a caching problem within ZODB3-3.9.0 dev
r77011,
my debug session tells:
/development/Zope3/MyProject/eggs/ZODB3-3.9.0_dev_r77011-py2.4-
macosx-10.4-ppc.egg/ZODB/Connection.py(644)_store_objects()
- raise
(Pdb) obj
zope.app.file.image.Image object at 0x3faadb0
(Pdb) oid
'\x00\x00\x00\x00\x00\x00\x00\xc6'
(Pdb) self._cache[oid]
*** KeyError: '\x00\x00\x00\x00\x00\x00\x00\xc6'
(Pdb) self._cache[oid] = obj
*** TypeError: Cache values must be persistent objects.
But zope.app.file.image.Image should be persistent.
[...]
Looking forward to some hints or help,
Hi Tobias. The ZODB 3.9 dev version is only different from 3.8 in
some conflict resolution code, for which I am responsible. Some
thoughts.
I'm pretty shure you ve got a LocationProxy arround your object
because the zope.app.file doesn't implement ILocation.
Hey Roger. I bet you are right.
...
Gary
-
This happens because of the call in
ZODB.Connection.py
$Id: Connection.py 75693 2007-05-11 22:18:37Z jim $
cool that we have the revision info in the file header ;-)
line: 627
except:
# Dang, I bet it's wrapped:
# TODO: Deprecate, then remove, this.
if hasattr(obj, 'aq_base'):
self._cache[oid] = obj.aq_base
else:
raise
My question is, can we improve the method:
if hasattr(obj, 'aq_base')
and remove the proxy with a method that works?
I mentioned this to Jim. If the masking of the original exception
doesn't appear to lose any useful information, he'd prefer something
like
if type(obj) is not obj.__class__:
raise ValueError('object appears to be proxied', obj)
else:
raise
IOW, don't guess, but give a more helpful error message
Gary___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zc.table.column.GetterColumn does not encode
Wednesday, July 18, 2007, 6:55:50 PM, I wrote: Hello, Seems like zc.table.column.GetterColumn does not encode the characters to the usual amp, lt, gt. Is that OK this way? I usually insert the result of the Formatter() with div tal:content=structure view/renderTable. That breaks havoc if a table cell's data contains any . Am I missing something? OK, silence is consent. I'll go ahead write a test and the fix and commit tomorrow. -- Best regards, Adammailto:[EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re[2]: problem with zope.testbrowser
Hello Philipp, I decided to keep the trunk consistent this time as I'm still not using the eggs. I'll wait for you (and Jim) to decide how to deal with the externals at the satellites. Monday, July 16, 2007, 10:49:38 PM, you wrote: On 16 Jul 2007, at 08:59 , Adam Groszer wrote: Yep, had the same idea just yesterday. But how to keep the trunk also in a good-consistent shape (if it needs to be kept in a good shape)? Well, that's a good question. If you'd like to update zope.testbrowser on the trunk, I suppose you'd have to do vendor imports of ClientForm and mechanize again. I think we'll pretty soon realize that the Zope3 trunk will become irrelevant, if not even a hindrance like in this case with vendor imports... -- Best regards, Adammailto:[EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zc.table.column.GetterColumn does not encode
On Jul 19, 2007, at 11:31 AM, Adam Groszer wrote: Wednesday, July 18, 2007, 6:55:50 PM, I wrote: Hello, Seems like zc.table.column.GetterColumn does not encode the characters to the usual amp, lt, gt. Is that OK this way? I usually insert the result of the Formatter() with div tal:content=structure view/renderTable. That breaks havoc if a table cell's data contains any . Am I missing something? OK, silence is consent. I'll go ahead write a test and the fix and commit tomorrow. +1 Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re[2]: problem with zope.testbrowser
Hello Philipp, Just realized that the mechanize and Clientform of the _satellite_ is pointing as external to the trunk... That looks not so good, does it? Monday, July 16, 2007, 10:49:38 PM, you wrote: On 16 Jul 2007, at 08:59 , Adam Groszer wrote: Yep, had the same idea just yesterday. But how to keep the trunk also in a good-consistent shape (if it needs to be kept in a good shape)? Well, that's a good question. If you'd like to update zope.testbrowser on the trunk, I suppose you'd have to do vendor imports of ClientForm and mechanize again. I think we'll pretty soon realize that the Zope3 trunk will become irrelevant, if not even a hindrance like in this case with vendor imports... -- Best regards, Adammailto:[EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re[2]: problem with zope.testbrowser
On 7/19/07, Adam Groszer [EMAIL PROTECTED] wrote: Just realized that the mechanize and Clientform of the _satellite_ is pointing as external to the trunk... That looks not so good, does it? Not good at all. :-( -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re[2]: problem with zope.testbrowser
On 19 Jul 2007, at 18:16 , Fred Drake wrote: On 7/19/07, Adam Groszer [EMAIL PROTECTED] wrote: Just realized that the mechanize and Clientform of the _satellite_ is pointing as external to the trunk... That looks not so good, does it? Not good at all. :-( Adam's email was a bit misleading, I think. Yes, the externals point to a trunk, but it's the Zope 3 trunk and they're also using fixed revisions: $ svn propget svn:externals svn+ssh://svn.zope.org/repos/main/ zope.testbrowser/trunk/src mechanize -r 69378 svn://svn.zope.org/repos/main/Zope3/trunk/src/ mechanize ClientForm -r 70384 svn://[EMAIL PROTECTED]/repos/main/Zope3/trunk/ src/ClientForm While this isn't great obviously, it's not as dramatic either. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re[2]: problem with zope.testbrowser
On 7/19/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Adam's email was a bit misleading, I think. Yes, the externals point to a trunk, but it's the Zope 3 trunk and they're also using fixed revisions: I got the Zope 3 trunk aspect, but didn't check the externals to see that they used specific revisions. This is certainly better. Adding an external egg to the install_requires would be even better, if anyone has time to work on this. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Dealing with external dependencies
On 19 Jul 2007, at 00:43 , Jim Fulton wrote: On Jul 18, 2007, at 5:24 PM, Philipp von Weitershausen wrote: Up until now we've been a bit sloppy when it came to egg dependencies. Not specifying a version number or range basically means that the code in question assumes it will work with any future version of its dependency. Admittedly, setuptools doesn't exactly make it easy to say I depend on ZODB 3.8.x. Jim has proposed to add a syntax to setuptools to support this nicely but it's not there yet. So I guess we'll have to wait for that. Heads up: I've come to think that depending on major revisions/ series isn't going to work. I'll say more about that in a separate thread though. Now you tell us :). This was basically the equivalent of depending on a specific, well- known working version of the external package. I'm not sure what you mean here. The equivalent to what we did before is to depend on specific versions at the *application* level, by fixing a version in a application meta package or in a buildout. I guess. I propose to do the same for the external dependencies we have. So far I only count docutils as an actual egg dependency because mechanize, ClientForm and twisted are still packaged up in the egg that uses them (we should change that, too). I will therefore change zope.app.renderer to depend on docutils==0.4, unless there are objections. Depending on specific versions in library packages (as opposed to application packages or buildouts) is a recipe for disaster IMO. As soon as 2 packages depend on different externals, then those 2 packages won't be usable together. Good point. In the long run, it might be better to only reuse packages that offer some backward compatibility promises. Depending on a specific version will make the dependent packages less reusable. That makes sense. So, coming back to the real world: we have two issues at hand. One is docutils, one is zope.testbrowser which depends on mechanize and ClientForm (Adam is working on that, CCing him as well). With docutils I understand that it makes much sense to do this at application level. With mechanize and ClientForm I'm not so sure. What I *do* know is that the current situation (packaging them *inside* the zope.testbrowser egg) isn't ideal (same goes for twisted, btw). Should the next zope.testbrowser simply depend on any version of mechanize and ClientForm? [1] This problem has bitten us over at Grok because apparently Ubuntu has decided to deploy docutils 0.4.1 which doesn't seem to actually exist anywhere and therefore confuses zc.buildout. See https://bugs.launchpad.net/grok/+bug/126742. I'm fairly sure that this has nothing to do with version numbers. I suspect instead that it has something to do with the fact that all distributions are now installed as develop eggs on ubuntu. The locations of these eggs is actually site-packages. This sounds very wonky to me, but Phillip Eby says it is normal. It's actually necessary (to install these things as eggs) because many packages nowadays depend on entry points. One could argue, obviously, that their location (site-packages) isn't ideal... ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
Philipp von Weitershausen wrote at 2007-7-18 22:59 +0200: On 18 Jul 2007, at 21:13 , Dieter Maurer wrote: ... I prefer the standard approach: I see a framework -- Zope and a large number of application components that plug themself into the common framework. The application, in fact a complete collection of mini-applications is configured via objects in the ZODB and can be extended TTW. Right. This is what Martijn Faassen aptly calls the Zope 2000 development model. And it's probably about the farthest away from working together with other Python web frameworks I agree with this. and toning down Zope for an easier entry. But, Zope is quite easy on entry. I expect that the traditional Zope-the-application was easier to install and to build applications with than your new approach which requires: * paste * WSGI * zopeproject * the application package * one instance per application True, experts can combine different Python web frameworks -- but what part of the Zope audience will need this? True, Python experts can be more economic with their knowledge. But, it appears the things become more difficult for non-experts. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Dealing with external dependencies
Philipp von Weitershausen wrote at 2007-7-18 23:24 +0200: Up until now we've been a bit sloppy when it came to egg dependencies. Not specifying a version number or range basically means that the code in question assumes it will work with any future version of its dependency. Which often is not so bad. Many of my modules have been developped for ancient Zope versions and kept running for several Zope releases -- even major ones. Thus, unless I do not know whether a given package will *not* work will a given future version of a dependancy, I will not want to state the dependancy for the current version -- as chances are high that it will indeed work with the next few future versions. ... Things are a bit different with external dependencies (docutils, mechanize, ClientForm, twisted, etc.), I think. They bear a higher risk of breaking stuff for us in future releases, even if they're just minor releases, because we don't control them and their developers probably don't test their stuff with our code [1]. Back in the old days, we would do vendor imports or use revision tags for the externals. This was basically the equivalent of depending on a specific, well-known working version of the external package. I propose to do the same for the external dependencies we have. So far I only count docutils as an actual egg dependency because mechanize, ClientForm and twisted are still packaged up in the egg that uses them (we should change that, too). I will therefore change zope.app.renderer to depend on docutils==0.4, unless there are objections. Don't you drastically increase the risk of conflicts? As I understood in a different thread, you want to mix Zope eggs with other eggs from the complete Python community. Such eggs may have a dependency on the same external package than Zope -- and fixing the precise version by Zope can easily lead to conflicts. Please keep dependency requirements weak -- restrict only when you know it is necessary... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Dealing with external dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: On 19 Jul 2007, at 00:43 , Jim Fulton wrote: Depending on specific versions in library packages (as opposed to application packages or buildouts) is a recipe for disaster IMO. As soon as 2 packages depend on different externals, then those 2 packages won't be usable together. Good point. But not necessarily avoidable: if version 3 of library A depends on a feature provided by version 5 of library B, but version 7 of library C is incompatible with versions of library B 4, then those versions of A and C really *are* incompatible; that isn't an accidental clash. Library authors need to *minimize* their own depdendencies if they want to maximize their library's usefulness: that means avoiding depending on newer versions of libraries without *very( strong need (degrading gracefully, if possible). Another problem: the folks who manage your dependencies may not be very good at it: - They may remove old release versions, making it impossible to satisfy your dependency. - They may *replace* a release version (even more evil than removing it). - They may screw up SVN or CVS repository history (e.g., 'svn rename' will cause even a revision-specific external / checkout to break). In the long run, it might be better to only reuse packages that offer some backward compatibility promises. Depending on a specific version will make the dependent packages less reusable. That makes sense. So, coming back to the real world: we have two issues at hand. One is docutils, one is zope.testbrowser which depends on mechanize and ClientForm (Adam is working on that, CCing him as well). With docutils I understand that it makes much sense to do this at application level. With mechanize and ClientForm I'm not so sure. What I *do* know is that the current situation (packaging them *inside* the zope.testbrowser egg) isn't ideal (same goes for twisted, btw). That situation is a fork, which may be the lesser of evils, depending on how things work out, especially in the face of poor upstream release hygeine. Should the next zope.testbrowser simply depend on any version of mechanize and ClientForm? [1] This problem has bitten us over at Grok because apparently Ubuntu has decided to deploy docutils 0.4.1 which doesn't seem to actually exist anywhere and therefore confuses zc.buildout. See https://bugs.launchpad.net/grok/+bug/126742. I'm fairly sure that this has nothing to do with version numbers. I suspect instead that it has something to do with the fact that all distributions are now installed as develop eggs on ubuntu. The locations of these eggs is actually site-packages. This sounds very wonky to me, but Phillip Eby says it is normal. It's actually necessary (to install these things as eggs) because many packages nowadays depend on entry points. One could argue, obviously, that their location (site-packages) isn't ideal... System pythons be damned. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn6EQ+gerLs4ltQ4RAnJpAKCRI034pHc1a7MVLzblcS9Jegpn3QCfZgoW lE838s0c37QPT7GOuXTDM0M= =OW0w -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Dealing with external dependencies
On Jul 19, 2007, at 1:09 PM, Philipp von Weitershausen wrote: On 19 Jul 2007, at 00:43 , Jim Fulton wrote: On Jul 18, 2007, at 5:24 PM, Philipp von Weitershausen wrote: Up until now we've been a bit sloppy when it came to egg dependencies. Not specifying a version number or range basically means that the code in question assumes it will work with any future version of its dependency. Admittedly, setuptools doesn't exactly make it easy to say I depend on ZODB 3.8.x. Jim has proposed to add a syntax to setuptools to support this nicely but it's not there yet. So I guess we'll have to wait for that. Heads up: I've come to think that depending on major revisions/ series isn't going to work. I'll say more about that in a separate thread though. Now you tell us :). I just realized this over the weekend and even then wanted to discuss it with some folks. ... In the long run, it might be better to only reuse packages that offer some backward compatibility promises. Depending on a specific version will make the dependent packages less reusable. That makes sense. So, coming back to the real world: we have two issues at hand. One is docutils, one is zope.testbrowser which depends on mechanize and ClientForm (Adam is working on that, CCing him as well). With docutils I understand that it makes much sense to do this at application level. With mechanize and ClientForm I'm not so sure. What I *do* know is that the current situation (packaging them *inside* the zope.testbrowser egg) isn't ideal (same goes for twisted, btw). Agreed. Should the next zope.testbrowser simply depend on any version of mechanize and ClientForm? I hope so. :) [1] This problem has bitten us over at Grok because apparently Ubuntu has decided to deploy docutils 0.4.1 which doesn't seem to actually exist anywhere and therefore confuses zc.buildout. See https://bugs.launchpad.net/grok/+bug/126742. I'm fairly sure that this has nothing to do with version numbers. I suspect instead that it has something to do with the fact that all distributions are now installed as develop eggs on ubuntu. The locations of these eggs is actually site-packages. This sounds very wonky to me, but Phillip Eby says it is normal. It's actually necessary (to install these things as eggs) because many packages nowadays depend on entry points. One could argue, obviously, that their location (site-packages) isn't ideal... My objection isn't to install them as eggs, I'm a big fan of eggs, I'm just mystified by installing them as develop eggs. In any case, PJE tells me this is correct, so I need to deal with it. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Fwd: Prototype setuptools-specific PyPI index.
See the forwarded message. I just added the following in the buildout section of my ~/.buildout/default.cfg: index = http://download.zope.org/ppix Without it, refreshing a small buildout of mine takes 2m44s. With it, it takes about 15 seconds. Jim Begin forwarded message: From: Jim Fulton [EMAIL PROTECTED] Date: July 19, 2007 7:06:34 AM EDT To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Prototype setuptools-specific PyPI index. Over the past few months, we've struggled quite a bit with Python Package Index (PyPI) performance and stability. Thanks to the heroic efforts of Martin v. Löwis and others, performance and especially stability have improved quite a bit. Martin has demonstrated that, at least when running well, PyPI seems to answer most requests on the order of 7 miliseconds (around 150 requests per second) internally. That's not bad. Unfortunately for users, actual times can be quite a bit longer. For me at work, request take around 300 milliseconds. For Martin, they seem to take somewhat longer. 300 milliseconds isn't so bad for a request or two, however, easy install can easily make 10s or even hundreds of requests to satisfy a user request for a package. zc.buildout, when verifying that a large system with many tens of packages has the most up to date versions of each package can easily make thousands of requests. Why do setuptools and buildout make so many requests? If a package exposes more than one release, then setuptools checks the package's main PyPI page and the pages for each release. We need to be able to easily use older releases, so we can't hide old releases. Typical projects of ours have many old releases exposed. If setuptools was more clever in the way it searched PyPI, but it would still have to make a minimum of 2 requests per package for packages with multiple versions exposed. Another potential issue is that PyPI pages can be large. I've found it convenient to use PyPI package pages as the home page for many of my projects. I like to include package documentation in my project pages. Perhaps this is an abuse of PyPI, but it is very convenient for me and no one has complained. :) The zc.buildout pages are around 200K. That's a fair bit of data for setuptools to download and scan for download URLs. In the course of this discussion, I've realized that it doesn't make sense for setuptools to use the same interface that humans use. setuptools doesn't need to see all of the data that is useful to humans. Similarly, humans generally don't need to see all of the historical releases for a project. I suggested a simple page format designed just for setuptools. An alternative would be an xmlrpc API. I prefer pages because I think that, over time, the amount of requests from automated tools like easy_install and zc.buildout will increase substantially and ultimately, will overwhelm dynamic servers, even ones like PyPI that are reasonably fast. I also think that a simple static collection of pages will be easier to mirror and I think some number of geographic mirrors is likely to help some people. I promised to prototype the format I suggested. I've created and experimental prototype setuptools-specific package index at http://download.zope.org/ppix Going to that page gives brief instructions for using it with easy_install and zc.buildout. To see an individual package page, add the package name to the URL, as in: http://download.zope.org/ppix/setuptools/ A few things to note about this: - I don't expose a long package list at http://download.zope.org/ ppix/. The long package list would be expensive to download and supports a use case that I consider to be of negative value, which is installing packages with case-insensitive package names, I think it is important for humans to be able to search for packages using case-insensitive search terms, but I think that, after identifying a package, precise package names should be used. I think it is especially important that precise package names be used in package requirements. - There is a single page per package. This can greatly reduce the number of requests. Packages that store all of their distributions in PyPI and that don't have off-site home pages or download URLs can be scanned with a single request. Note that I excluded home page and download URLs that pointed back to the packages PyPI page, as that wouldn't provide any new information to setuptools. - Download URLs for *hidden* packages are included. Humans don't need to see old revisions, but setuptools-based tools do. If we used an index like this for setuptools, we could stop unhiding old releases when we created new releases in PyPI. This would make PyPI more useful to humans and less of a pain for developers. - Download URLs are the same as they are in PyPI. Using this new index,
Re: [Zope3-dev] RFC: zopeproject
On 7/19/07, Dieter Maurer [EMAIL PROTECTED] wrote: But, Zope is quite easy on entry. Zope2, yes. Zope3? Not at all. Will modularizing Zope 3 make it easier for newbies? Not really, but with zopeproject or similar it shouldn't be more complicated either. In fact, the installation process might end up being simpler: Compare: wget http://www.zope.org/whatevah/Zope.tgz tar xvfz thetgz ./configure make make install make instance directory With: easy_install zopeproject zopeproject directory cd directory bin/buildout Or something similar to that. Doesn't really look more complicated to me. :-) Sure, it uses paste and stuff, but you don't have to know about that to use it. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: zopeproject
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: On 7/19/07, Dieter Maurer [EMAIL PROTECTED] wrote: But, Zope is quite easy on entry. Zope2, yes. Zope3? Not at all. Will modularizing Zope 3 make it easier for newbies? Not really, but with zopeproject or similar it shouldn't be more complicated either. In fact, the installation process might end up being simpler: Compare: wget http://www.zope.org/whatevah/Zope.tgz tar xvfz thetgz ./configure make make install make instance directory With: easy_install zopeproject zopeproject directory cd directory bin/buildout Or something similar to that. Doesn't really look more complicated to me. :-) Sure, it uses paste and stuff, but you don't have to know about that to use it. I think we need to leave soem space for people who want to customize the site, without wanting to do full-on Zope3 package-based development. If zopeproject makes it obvious where to put filesystem pages, people will use them, probably. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn86a+gerLs4ltQ4RAhhaAKCKHbmXXHyYHRrLfmNwSntE+sxrOwCeI0Mq zbxxqSUrW10QZEsfSy0/pts= =ZHFW -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Dealing with external dependencies
On 19 Jul 2007, at 19:36 , Dieter Maurer wrote: ... Things are a bit different with external dependencies (docutils, mechanize, ClientForm, twisted, etc.), I think. They bear a higher risk of breaking stuff for us in future releases, even if they're just minor releases, because we don't control them and their developers probably don't test their stuff with our code [1]. Back in the old days, we would do vendor imports or use revision tags for the externals. This was basically the equivalent of depending on a specific, well-known working version of the external package. I propose to do the same for the external dependencies we have. So far I only count docutils as an actual egg dependency because mechanize, ClientForm and twisted are still packaged up in the egg that uses them (we should change that, too). I will therefore change zope.app.renderer to depend on docutils==0.4, unless there are objections. Don't you drastically increase the risk of conflicts? Yes, probably. I've been convinced now that making libraries depend on specific versions isn't such a good idea. Thanks for the input. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 19 Jul 2007, at 19:15 , Dieter Maurer wrote: and toning down Zope for an easier entry. But, Zope is quite easy on entry. To some, probably many, it is easy. At first. Then they discover the limits of TTW development and hit the wall of having to learn this completely new and different way of doing Zope development (products instead of TTW). I also know a fair number of people who were simply so confused by this ZMI thing and the whole concept of TTW development (mostly because it's so different than *anything* else out there, and they couldn't use their favourite tools) that they swore never to do anything with Zope. They didn't even get to the good stuff (filesystem-based development). I expect that the traditional Zope-the-application was easier to install and to build applications with than your new approach which requires: * paste * WSGI These two are not only used by many other web frameworks, they're also documented by them. That means we can share not only code and knowledge but also documentation efforts. Having standards like these two is good. Look at Java. The Servlet or Portlet APIs are probably not the prettiest ones, but sure everybody who ever has to do anything with them will find tons of docs on them. And s/he will be able to use that knowledge, once gained, pretty much everywhere. * zopeproject * the application package * one instance per application True, experts can combine different Python web frameworks -- but what part of the Zope audience will need this? A great consequence of WSGI are middlewares. They're general purpose applications that plug between a server gateway and a WSGI application, be it Pylons, TurboGears or Zope. These are not really frameworks, but more filters that are easy to re-use. In my talk Zope on a Paste at the DZUG and EuroPython conferences, I've demonstrated a number of general purpose middlewares that are completely third-party to Zope. They include simple things like logging and gzipping as well as very useful things like interactive debugging and XSLT-based theming. And the best thing is that they can be plugged in by a mere 2-4 lines of configuration. So basically they're useful and easy to use. I think *lots* of people in the Zope audience will find them useful. At least the audiences both times I've given the talk seemed to welcome the idea quite a lot. True, Python experts can be more economic with their knowledge. But, it appears the things become more difficult for non-experts. In a blog post [1] that I wrote a while ago, I've collected my thoughts on why I think TTW development is a failed model, *especially* for beginners. Instead of posting these thoughts here, I'll simply link to it and invite you to read it. In a follow up to that post [2], I was able to report proof, so to speak, that the standard, down to earth Python approach (in the form of Grok) actually fitted people's brains much better. It fitted so well that we had people contributing to Grok that hadn't worked with Zope3 or Grok at all a few months or even weeks before that. At the EuroPython sprint last week, we could again observe the same happening. [1] http://www.z3lab.org/sections/blogs/philipp-weitershausen/ 2007_03_27_meet-grok-successor [2] http://www.z3lab.org/sections/blogs/philipp-weitershausen/ 2007_04_19_why-zclasses-dead-why ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] problem with zope.testbrowser
On 19 Jul 2007, at 19:10 , Fred Drake wrote: On 7/19/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Adam's email was a bit misleading, I think. Yes, the externals point to a trunk, but it's the Zope 3 trunk and they're also using fixed revisions: I got the Zope 3 trunk aspect, but didn't check the externals to see that they used specific revisions. This is certainly better. Adding an external egg to the install_requires would be even better, if anyone has time to work on this. Well Adam seems to want to work on this. It's what I suggested he should do. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: zopeproject
On 19 Jul 2007, at 22:50 , Tres Seaver wrote: Lennart Regebro wrote: On 7/19/07, Dieter Maurer [EMAIL PROTECTED] wrote: But, Zope is quite easy on entry. Zope2, yes. Zope3? Not at all. Will modularizing Zope 3 make it easier for newbies? Not really, but with zopeproject or similar it shouldn't be more complicated either. In fact, the installation process might end up being simpler: Compare: wget http://www.zope.org/whatevah/Zope.tgz tar xvfz thetgz ./configure make make install make instance directory With: easy_install zopeproject zopeproject directory cd directory bin/buildout Or something similar to that. Doesn't really look more complicated to me. :-) Sure, it uses paste and stuff, but you don't have to know about that to use it. I think we need to leave soem space for people who want to customize the site, without wanting to do full-on Zope3 package-based development. If zopeproject makes it obvious where to put filesystem pages, people will use them, probably. I would actually like to leave the customizeable/pluggable app story to another project, mostly because it's a concern that's orthogonal to zopeproject. zopeproject is actually general enough (or at least it tries to be) so that it can be used to bootstrap applications that build on top of Zope. Grok is a good example, grokproject uses zopeproject under the hood. (Grok, in a way, makes things a lot easier for the middleclass programmer anyway, perhaps enough for people to feel comfortable with it as a means for customizing existing apps, e.g. Plone) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 19 Jul 2007, at 22:35 , Lennart Regebro wrote: On 7/19/07, Dieter Maurer [EMAIL PROTECTED] wrote: But, Zope is quite easy on entry. Zope2, yes. Zope3? Not at all. Will modularizing Zope 3 make it easier for newbies? Not really, but with zopeproject or similar it shouldn't be more complicated either. That's *exactly* the point of zopeproject. You get more for the same price :). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Dealing with external dependencies
On 19 Jul 2007, at 20:12 , Jim Fulton wrote: On Jul 19, 2007, at 1:09 PM, Philipp von Weitershausen wrote: On 19 Jul 2007, at 00:43 , Jim Fulton wrote: On Jul 18, 2007, at 5:24 PM, Philipp von Weitershausen wrote: Up until now we've been a bit sloppy when it came to egg dependencies. Not specifying a version number or range basically means that the code in question assumes it will work with any future version of its dependency. Admittedly, setuptools doesn't exactly make it easy to say I depend on ZODB 3.8.x. Jim has proposed to add a syntax to setuptools to support this nicely but it's not there yet. So I guess we'll have to wait for that. Heads up: I've come to think that depending on major revisions/ series isn't going to work. I'll say more about that in a separate thread though. Now you tell us :). I just realized this over the weekend and even then wanted to discuss it with some folks. Fair enough. Should the next zope.testbrowser simply depend on any version of mechanize and ClientForm? I hope so. :) Ok. Adam, those seem like clear instructions :). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] problem with zope.testbrowser
On 7/19/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Well Adam seems to want to work on this. It's what I suggested he should do. Three cheers for Adam! -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: [Zope3-dev] Re: Problems with zope3 on windows
Hi, On Thu, 2007-07-19 at 14:05 +0200, Roger Ineichen wrote: Hi Hanno -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Hanno Schlichting [...] Full tracebacks are available in the thread from May/June at http://mail.zope.org/pipermail/zope3-dev/2007-June/022752.html The problem is still that zc.zope3recipes uses zopectl and in turn zdaemon which don't work on Windows. As outlined in the old thread this is a known problem and not that hard to fix. Right it uses zdaemon which doens't fit for windows. Currently it justs needs someone to sit down and do the work. I myself won't do it, as I only use Zope 3 through Zope 2 where all this has already been fixed ;) Can you point me to the right repos/place of this allready fixed issue in Zope2. So I can take a look at that and fix it if I find out how this eggs work. This just got a mention too on the grok-dev list [1]. Tres pointed to: http://svn.zope.org/Zope/?rev=75066view=rev [1] http://mail.zope.org/pipermail/grok-dev/2007-July/001645.html Regards, Darryl Regards Roger Ineichen Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/darryl%40darrylcousins.net.nz ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On 18 Jul 2007, at 19:25 , Kent Tenney wrote: on my W2K machine zopeproject MyZopeProject fails because I don't have Visual Studio installed and it wants to compile extensions for ZODB Right. Something seems to depend on ZODB 3.9.0-xyz now and we have no binary for that (yet). Sadly enough, I recently asked Jim to make Windows eggs and they've all become useless because at least half of the packages now have newer releases (which buildout insists on using). I've heard that mingw can substitute, but I've never succeeded in configuring it. Well, I managed to install it (you need cygwin, then install the gcc- mingw-core package from the 'devel' section). And with 'python setup.py build -c mingw32', it seems I can even build Windows eggs, though I can't get them to work. I get some a DLL error (Access denied.) What's more, there seems to be now way to tell zc.buildout to pass the '-c mingw32' option to setup.py when building eggs. I wonder, if done correctly (and I believe some people, e.g. Andreas Jung, have managed to get mingw to build binary eggs for them), are mingw-based eggs any worse than Visual C ones? If not, then there's a good chance that we can actually get a setup for Windows people that won't require Jim or Adam having to build Windows eggs all the time. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: zopeproject
Hi, Philipp von Weitershausen wrote: On 18 Jul 2007, at 19:25 , Kent Tenney wrote: on my W2K machine zopeproject MyZopeProject fails because I don't have Visual Studio installed and it wants to compile extensions for ZODB Right. Something seems to depend on ZODB 3.9.0-xyz now and we have no binary for that (yet). Sadly enough, I recently asked Jim to make Windows eggs and they've all become useless because at least half of the packages now have newer releases (which buildout insists on using). I've heard that mingw can substitute, but I've never succeeded in configuring it. Have you seen my instructions for a Plone 3.0 buildout at http://svn.plone.org/svn/plone/ploneout/trunk/WINDOWS.txt ? This is the most reliable and easiest way I could find to compile C extensions on Windows without having to have any special M$ compiler. Well, I managed to install it (you need cygwin, then install the gcc-mingw-core package from the 'devel' section). And with 'python setup.py build -c mingw32', it seems I can even build Windows eggs, though I can't get them to work. I get some a DLL error (Access denied.) What's more, there seems to be now way to tell zc.buildout to pass the '-c mingw32' option to setup.py when building eggs. My instructions tell you to use MinGW directly without all that Cygwin junk which only tends to make things more complicated and often introduces an undesired runtime dependency on Cygwin. The nice thing as noted in my howto is that you can change a distutils option to say all build commands should use mingw32 and so all buildout recipes will pick this up. I wonder, if done correctly (and I believe some people, e.g. Andreas Jung, have managed to get mingw to build binary eggs for them), are mingw-based eggs any worse than Visual C ones? A few years ago, MinGW (the native port is still based on GCC 3.4) compiled C extensions were a bit slower than those compiled with Visual C. But I haven't tried this in recent years. My knowledge of C compilation is too limited to judge if there are some hidden pitfalls here, though. Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: RFC: zopeproject
Hi again. Hanno Schlichting wrote: Philipp von Weitershausen wrote: I wonder, if done correctly (and I believe some people, e.g. Andreas Jung, have managed to get mingw to build binary eggs for them), are mingw-based eggs any worse than Visual C ones? A few years ago, MinGW (the native port is still based on GCC 3.4) compiled C extensions were a bit slower than those compiled with Visual C. But I haven't tried this in recent years. My knowledge of C compilation is too limited to judge if there are some hidden pitfalls here, though. In order to let some people judge the result of eggs built based on my howto I made one example egg for zope.interface 3.4.0. The egg is available from http://www.hannosch.de/zope.interface-3.4.0-py2.4-win32.egg The relevant log from the bdist_egg looks like this: running build_ext building '_zope_interface_coptimizations' extension creating build\temp.win32-2.4 creating build\temp.win32-2.4\Release creating build\temp.win32-2.4\Release\src creating build\temp.win32-2.4\Release\src\zope creating build\temp.win32-2.4\Release\src\zope\interface C:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -IC:\Python24\include -IC:\Python24\PC -c src\zope\interface\_zope_interface_coptimizations.c -o build\temp.win32-2.4\Release\src\zope\interface\_zope_interface_coptimizations.o writing build\temp.win32-2.4\Release\src\zope\interface\_zope_interface_coptimizations.def C:\MinGW\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.4\Release\src\zope\interface\_zope_interface_coptimizations.o build\temp.win32-2.4\Release\src\zope\interface\_zope_interface_coptimizations.def -LC:\Python24\libs -LC:\Python24\PCBuild -lpython24 -lmsvcr71 -o build\lib.win32-2.4\zope\interface\_zope_interface_coptimizations.pyd Python is version 2.4.4, GCC is 3.4.2 (mingw-special). If someone tells me, that the eggs I generate this way are valid and of some use, I'm happy to help to build some more ;) Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: zopeproject
On Jul 19, 2007, at 6:46 PM, Philipp von Weitershausen wrote: On 18 Jul 2007, at 19:25 , Kent Tenney wrote: on my W2K machine zopeproject MyZopeProject fails because I don't have Visual Studio installed and it wants to compile extensions for ZODB Right. Something seems to depend on ZODB 3.9.0-xyz now zope.app.keyreference 3.5.0dev xxx. stick to the 3.4 line to keep away. and we have no binary for that (yet). Sadly enough, I recently asked Jim to make Windows eggs and they've all become useless because at least half of the packages now have newer releases (which buildout insists on using). (Well, not if you give it constraints.) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
