[Zope-dev] Re: SVN: zope.app.dependable/trunk/setup.py Silly version bump.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > Log message for revision 81020: > Silly version bump. I agree that it is silly; having to keep readjusting the trunk is one of the reasons why I favor having just 'trunk/unreleased' as the version in setup.py on the trunk (and 'x.y-branch' on the branch). The other reason, of course, is that such bogus release numbers make it less tempting to release from a trunk or branch checkout without first making a tag and checking it out: th tag is the only place where the version number is not either a lie or a potential time bomb. > Changed: > U zope.app.dependable/trunk/setup.py > > -=- > Modified: zope.app.dependable/trunk/setup.py > === > --- zope.app.dependable/trunk/setup.py2007-10-24 02:39:08 UTC (rev > 81019) > +++ zope.app.dependable/trunk/setup.py2007-10-24 02:40:57 UTC (rev > 81020) > @@ -22,7 +22,7 @@ > return open(os.path.join(os.path.dirname(__file__), *rnames)).read() > > setup(name='zope.app.dependable', > - version = '3.4.0', > + version = '3.4.1', >author='Zope Corporation and Contributors', >author_email='[EMAIL PROTECTED]', >description='Simple Dependency API', Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHrle+gerLs4ltQ4RAoObAJ9QeeU5na/xF1u2Pn5VZhNYJhd4EACeJPX7 KXIQJfIziNTROMtkND3M6lI= =q7jT -END PGP SIGNATURE- ___ 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: [Plone-developers] zcml entry points
On Oct 22, 2007, at 11:46 AM, Lennart Regebro wrote: On 10/22/07, Martijn Faassen <[EMAIL PROTECTED]> wrote: In at least 3 places we express dependency information. For different *purposes* in each case, but we still state something like: 1. "we use dependency X, and please download and install it" 2. "we use dependency X, please configure it" 3. "we use dependency X, please import the following from it" It'd be nice if I only had to say "I want to import from dependency X, please make sure it's there and available." Actually this is a little bit like zc.resourcelibrary can make resources appear on your page headers when you write code that needs it. Of course this is sometimes not possible, as there's not enough information available, or there are multiple separate ways to configure it. In the end I guess this all is just more arguments for separating the functions and the views into separate eggs. I think maybe more abstractly, it might be useful to think about separating based on libraries vs. applications. Libraries should be as policy-free as possible (otherwise they're not libraries, they're applications). Applications, however, must declare policies (or they would be useless, this is what makes them applications [sorry for the reflexive tautology]), but this makes them not useful outside of some context. If a library egg contains an entry point that either loaded or returned a stream for the moral equivalent of meta.zcml, that would be fine. But it would be less OK for an egg which represented a library's ZCML to contain adapter and utlity registrations. However, if the egg represented an application, it would be fine for it to do either. Zope 2 'Products' are usually applications in a sense, because they are *never* useful outside the context of Zope-the-application- server, and that's why Five's automagical load of "meta", "configure", and "overrides" ZCML is completely appropriate for them, and why it would make sense, if products became eggs, to have all of their ZCML loaded at Zope startup time. However, the presence of some ZCML in a non-Product library doesn't mean that its ZCML should be loaded, IMO. Zope-3-the-application uses site.zcml to selectively load configurations, and I think that's about the right policy. We could devise some way of spelling the equivalent of site.zcml as an entry point for eggs-that-are-applications, and as any "include package" directives in that zcml should "just work", there probably shouldn't be any additional machinery within zcml itself to cause other ZCML to be loaded from multiple packages via some omnibus search pattern. We don't really complain too badly right now that setuptools doesn't infer all of our dependencies for us from import statements in the packages it contains in order to prevent us from having to manually specify dependencies in our setup.py. This is because even though it probably could (py2exe does something like this), it's more trouble than it's worth in because the import statements themselves don't contain enough information (version, location, is it an absolute requirement or a nice-to-have?) if you want to treat the dependencies as independently release-managed entities. That said, if you just want to "freeze" some configuration up, it would become reasonable to treat some sandbox as a fully-configured set of things that should get packaged up as a glob and shipped off, but this is the opposite of what we want to do with eggs in the long term, I think. - C ___ 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] Snow-Sprint 2008
Lovely Systems is proud to announce the 5th Snow-Sprint in a row. Between Friday 18th of January 2007 and 25th we’ll code, talk, eat, drink, sleep, ski, snowboard in the Austrian Alps. Sprint organisation is done on http://www.openplans.org/projects/snow- sprint-2008 We’ll definitely focus on Zope3 and High Traffic related topics - Plone People welcome! Highlight the week in your calendar, add your name to the Openplans Wiki and book your flight. More details will be added to the wiki on the fly. See you in the mountains! Jodok and the lovely team -- "Namespaces are one honking great idea -- let's do more of those!" -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ 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: SVN: Zope/trunk/ Moved two implements declarations from Five into the proper classes.
On 23/10/2007, Dieter Maurer <[EMAIL PROTECTED]> wrote: > Laurence Rowe wrote at 2007-10-23 12:00 +0100: > >Lennart Regebro wrote: > > ... > >> I guess we need to either actually implement the relevant interfaces, > >> or split the interfaces into something that can be implemented... > >> > > > >Preferably not too far down the class hierarchy. It would be useful for > >things such as cmf's PortalFolder not to implement IContainer directly, > >it makes non-zodb content much easier if an adapter can be used. > > Are you abusing adapters? > > If not, it should not matter whether the object implements > an interface directly or whether an adapter is needed... Possibly, but I just want the higher level CMF functionality without assumptions about the lower level functionality (would not be a problem in a pure zope 3 environment). Laurence ___ 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: SVN: Zope/trunk/ Moved two implements declarations from Five into the proper classes.
Laurence Rowe wrote at 2007-10-23 12:00 +0100: >Lennart Regebro wrote: > ... >> I guess we need to either actually implement the relevant interfaces, >> or split the interfaces into something that can be implemented... >> > >Preferably not too far down the class hierarchy. It would be useful for >things such as cmf's PortalFolder not to implement IContainer directly, >it makes non-zodb content much easier if an adapter can be used. Are you abusing adapters? If not, it should not matter whether the object implements an interface directly or whether an adapter is needed... -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/trunk/lib/python/DateTime/ tidy up legacy time zones
In response to Laurence Rowe's checkin: http://svn.zope.org/Zope/?rev=80958&view=rev Sidnei da Silva wrote: > May I ask why the 'Brazil/DeNoronha' timezone was commented out? > AFAICT, it's a valid timezone. At least I can find several references, > one of which seems to imply that 'Brazil/DeNoronha' is an alias to > 'America/Noronha'. > > http://www.tldp.org/HOWTO/TimePrecision-HOWTO/tz.html > http://dev.joyent.com/projects/connector/browse/trunk/vendor/gems/tzinfo-0.3.4/lib/tzinfo/definitions/Brazil/DeNoronha.rb?rev=414 Laurence Rowe wrote: > There was no data for it. Trying to retrieve it from the _tzinfo cache > resulted in a KeyError, it's not in pytz.common_timezones or the > _zmap. > > 'America/Noronha' is not in pytz.common_timezones either. > > Laurence There *is* data for the zone in DateTimeZone.py, however; I'm pretty wure that we are supposed to fall back to that data if pytz misses; otherwise we risk breaking old pickles. Amos, can you confirm? Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Mon Oct 22 12:00:00 2007 UTC to Tue Oct 23 12:00:00 2007 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Oct 22 20:49:46 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008531.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Mon Oct 22 20:51:16 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008532.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Oct 22 20:52:46 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008533.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Oct 22 20:54:17 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008534.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Mon Oct 22 20:55:47 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-October/008535.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/trunk/ Moved two implements declarations from Five into the proper classes.
Lennart Regebro wrote: On 10/23/07, Laurence Rowe <[EMAIL PROTECTED]> wrote: Philipp von Weitershausen wrote: Hanno Schlichting wrote: Log message for revision 80945: Moved two implements declarations from Five into the proper classes. I object to this change. HTTPRequest does not really fulfil the IBrowserRequest interface, and ObjectManager isn't a real IContainer either. I understand that somebody made a mistake when they declared them as such in the early days of Five. This is the reason we can't take it back. But, at least as a sign of the fact that they're not (yet) the real deal, this declaration has remained in ZCML. A sensible step forward would be to make HTTPRequest a full IBrowserRequest (we're getting there). As for ObjectManager, I think IContainer implies a couple of semantics (such as unicode names, the sending of events, etc.) that we should look closer at before deciding. I've found the fact that ObjectManager implements IContainer to be a problem in my application where I have a mixin implementing then ObjectManager expectations by adapting to IContainer (this allows most of my code to be zope 3 like with the zope 2 compatibility contained). I've had to subclass IContainer and adapt to my subclass instead. The only place I've run into problems using unicode names is in the ZCatalog (or maybe CatalogTool) where there is a test that a name isinstance str. I guess we need to either actually implement the relevant interfaces, or split the interfaces into something that can be implemented... Preferably not too far down the class hierarchy. It would be useful for things such as cmf's PortalFolder not to implement IContainer directly, it makes non-zodb content much easier if an adapter can be used. ___ 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: SVN: Zope/trunk/ Moved two implements declarations from Five into the proper classes.
On 10/23/07, Laurence Rowe <[EMAIL PROTECTED]> wrote: > Philipp von Weitershausen wrote: > > Hanno Schlichting wrote: > >> Log message for revision 80945: > >> Moved two implements declarations from Five into the proper classes. > > > > I object to this change. HTTPRequest does not really fulfil the > > IBrowserRequest interface, and ObjectManager isn't a real IContainer > > either. I understand that somebody made a mistake when they declared > > them as such in the early days of Five. This is the reason we can't take > > it back. But, at least as a sign of the fact that they're not (yet) the > > real deal, this declaration has remained in ZCML. > > > > A sensible step forward would be to make HTTPRequest a full > > IBrowserRequest (we're getting there). As for ObjectManager, I think > > IContainer implies a couple of semantics (such as unicode names, the > > sending of events, etc.) that we should look closer at before deciding. > > > > I've found the fact that ObjectManager implements IContainer to be a > problem in my application where I have a mixin implementing then > ObjectManager expectations by adapting to IContainer (this allows most > of my code to be zope 3 like with the zope 2 compatibility contained). > I've had to subclass IContainer and adapt to my subclass instead. > > The only place I've run into problems using unicode names is in the > ZCatalog (or maybe CatalogTool) where there is a test that a name > isinstance str. I guess we need to either actually implement the relevant interfaces, or split the interfaces into something that can be implemented... -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/trunk/ Moved two implements declarations from Five into the proper classes.
Philipp von Weitershausen wrote: Hanno Schlichting wrote: Log message for revision 80945: Moved two implements declarations from Five into the proper classes. I object to this change. HTTPRequest does not really fulfil the IBrowserRequest interface, and ObjectManager isn't a real IContainer either. I understand that somebody made a mistake when they declared them as such in the early days of Five. This is the reason we can't take it back. But, at least as a sign of the fact that they're not (yet) the real deal, this declaration has remained in ZCML. A sensible step forward would be to make HTTPRequest a full IBrowserRequest (we're getting there). As for ObjectManager, I think IContainer implies a couple of semantics (such as unicode names, the sending of events, etc.) that we should look closer at before deciding. I've found the fact that ObjectManager implements IContainer to be a problem in my application where I have a mixin implementing then ObjectManager expectations by adapting to IContainer (this allows most of my code to be zope 3 like with the zope 2 compatibility contained). I've had to subclass IContainer and adapt to my subclass instead. The only place I've run into problems using unicode names is in the ZCatalog (or maybe CatalogTool) where there is a test that a name isinstance str. Laurence ___ 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] formlib does not implement IFormAPI
The IFormAPI interface documents a css_class option for Action, but when I try to use that I get an error. This makes it quite hard to style buttons and hook client-side behaviour to them. Is that an oversight that should be fixed, or was it the intention to not support css_class and hasn't it been removed from the interface yet? Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 )
