[Zope-dev] Proposal: merge zc.configuration's exclude directive into zope.configuration.
Hi there. The exclude directive provided by zc.configuration package is easy to use and straightforward. I think it's used almost in every zope-based application setup. Its implementation is very small and fits great in zope.configuration's standard directives. So I'd like to propose to move it to zope.configuration and make it always available for ZMCL files, just like the include directive, so people would'nt need to install extra package and include an extra meta.zcml file before being able to use it. If noone objects, I'd like to do that and make the exclude directive from zc.configuration point to the zope.configuration's implementation making the original place deprecated (however I guess the whole zc.configuration package should't be deprecated as it's intended to be a common place for configuration extensions, even if it has only one directive now). Jim, if you're fine with that, can you please give me rights for zc.configuration on PYPI, my user name is nadako. -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope.pipeline proposal
Hi there, One issue I have with using paste deploy's pipeline configuration for endware is that such configuration sometimes really wants to be part of a library. I.e. I don't want to configure a tower of endwares each time I write an application, I want to reuse some premade configuration that comes along with some released library. This as opposed to middleware. The middleware is generic across WSGI servers and the person who decides to use it is frequently the developer. That said, there's likely a grey area between the two. Perhaps there's a way you can use paste's mechanism and ship it in a library. If not, you'll end up stacking together WSGI's in Python code. I can then see the benefit in a declarative version of this that can ship along with a library. With the right application of grokkers that could probably be made to look very compact too. :) Regards, Martijn ___ 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] [Checkins] SVN: Zope/trunk/README.txt The zope-lice...@zope.org address is bouncing.
Can anyone please verify this change. As it is related to license, I thought just get confirmation from here. Regards, Baiju M On Thu, Feb 26, 2009 at 4:58 PM, Baiju M baiju.m.m...@gmail.com wrote: Log message for revision 97294: The zope-lice...@zope.org address is bouncing. So, replaced it with zope-dev@zope.org Changed: U Zope/trunk/README.txt -=- Modified: Zope/trunk/README.txt === --- Zope/trunk/README.txt 2009-02-26 11:23:12 UTC (rev 97293) +++ Zope/trunk/README.txt 2009-02-26 11:28:04 UTC (rev 97294) @@ -21,7 +21,7 @@ --- The Zope License is included in ``ZopePublicLicense.txt``. Send your -feedback about the license to zope-lice...@zope.org. +feedback about the license to zope-...@zope.org. Bug tracker --- ___ Checkins mailing list check...@zope.org http://mail.zope.org/mailman/listinfo/checkins ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: merge zc.configuration's exclude directive into zope.configuration.
Hey, Dan Korostelev wrote: The exclude directive provided by zc.configuration package is easy to use and straightforward. I think it's used almost in every zope-based application setup. I highly doubt so; I don't find myself using it a lot myself, for instance. :) Its implementation is very small and fits great in zope.configuration's standard directives. So I'd like to propose to move it to zope.configuration and make it always available for ZMCL files, just like the include directive, so people would'nt need to install extra package and include an extra meta.zcml file before being able to use it. +1 (note though that including an extra meta.zcml can be avoided if you make use of the z3c.autoinclude library) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: merge zc.configuration's exclude directive into zope.configuration.
2009/2/26 Martijn Faassen faas...@startifact.com: Dan Korostelev wrote: The exclude directive provided by zc.configuration package is easy to use and straightforward. I think it's used almost in every zope-based application setup. I highly doubt so; I don't find myself using it a lot myself, for instance. :) Well, may be, really not in every app, but it's still used alot. :-) (note though that including an extra meta.zcml can be avoided if you make use of the z3c.autoinclude library) Yep, I know about z3c.autoinclude, but I don't like it, as it makes things more implicit and it also slows down startup time for applications that uses many eggs. I'd like to see an option for packages that are using z3c.autoinclude to make autoincluding conditional, so those who doesn't like it or needs more control could just turn it off. -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: merge zc.configuration's exclude directiveinto zope.configuration.
2009/2/26 Roger Ineichen d...@projekt01.ch: (note though that including an extra meta.zcml can be avoided if you make use of the z3c.autoinclude library) Oh, cool. Now we only need to find out how to write an z3c.autoexlude and a z3c.autooverride library ;-) :-)) +1 -- WBR, Dan Korostelev ___ 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] [Checkins] SVN: Zope/trunk/README.txt The zope-lice...@zope.org address is bouncing.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My suggestion would be foundation-i...@zope.org, since the ZF is the publisher of the ZPL at this point. jens On Feb 26, 2009, at 12:32 , Baiju M wrote: Can anyone please verify this change. As it is related to license, I thought just get confirmation from here. Regards, Baiju M On Thu, Feb 26, 2009 at 4:58 PM, Baiju M baiju.m.m...@gmail.com wrote: Log message for revision 97294: The zope-lice...@zope.org address is bouncing. So, replaced it with zope-dev@zope.org Changed: U Zope/trunk/README.txt -=- Modified: Zope/trunk/README.txt === --- Zope/trunk/README.txt 2009-02-26 11:23:12 UTC (rev 97293) +++ Zope/trunk/README.txt 2009-02-26 11:28:04 UTC (rev 97294) @@ -21,7 +21,7 @@ --- The Zope License is included in ``ZopePublicLicense.txt``. Send your -feedback about the license to zope-lice...@zope.org. +feedback about the license to zope-...@zope.org. Bug tracker --- ___ Checkins mailing list check...@zope.org http://mail.zope.org/mailman/listinfo/checkins ___ 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 ) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmmgTsACgkQRAx5nvEhZLJp6ACfSxfTBQ/77UNVhV15WVE8lqxs bCkAni2IvAt3NH1pqxUK1z7uxLVtICys =Toug -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 )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Wed Feb 25 12:00:00 2009 UTC to Thu Feb 26 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Wed Feb 25 20:23:18 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011187.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Feb 25 20:25:21 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011188.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Wed Feb 25 20:27:21 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011189.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Wed Feb 25 20:29:21 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011190.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Wed Feb 25 20:31:21 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011191.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Wed Feb 25 20:33:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011192.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 )
Re: [Zope-dev] Proposal: merge zc.configuration's exclude directive into zope.configuration.
Hey, On Thu, Feb 26, 2009 at 12:43 PM, Dan Korostelev nad...@gmail.com wrote: [snip] (note though that including an extra meta.zcml can be avoided if you make use of the z3c.autoinclude library) Yep, I know about z3c.autoinclude, but I don't like it, as it makes things more implicit and it also Yes, automation makes things more implicit. This is *not* an argument that can be used against any and all automation. An explicit includeDependencies directive will include the configure.zcml and meta.zcml of packages that are dependencies of that package. You make less mistakes this way (and it's very common to make the mistake to forget inclusion of some ZCML). It's also pretty rare to want to do otherwise in my experience (and there's always the exclude directive). I'd also argue auto-inclusion can actually help guard against dependency bugs, such as cases where a package tries to include ZCML it doesn't depend on (and works because some other package makes the dependency installed). slows down startup time for applications that uses many eggs. When claims like that are made, I'd like to see measurements that demonstrate significant slowdowns during startup. Undoubtedly more code is excuted than when you write out 'include' directives manually, but is the slowdown actually measurable? I'd like to see an option for packages that are using z3c.autoinclude to make autoincluding conditional, so those who doesn't like it or needs more control could just turn it off. That's asking for a feature that other packages that *don't* use autoinclude don't support! You lose control as soon as you include a package's configure.zcml. There's no difference with non-auto-inclusion here; if you include a package's configure.zcml you get whatever it includes, automatically or using normal zcml include directives. When auto-inclusion is used all dependencies that use setup.py are included too. If you want to change that behavior, you will have to skip importing that package's configure.zcml altogether, just like in the case where that package does write its include statements out explicitly. Anyway, it's fine if you don't want to use auto-inclusion in a package, but it's not as arbitrarily magic as you are suggesting here. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: merge zc.configuration's exclude directiveinto zope.configuration.
Hi there, On Thu, Feb 26, 2009 at 12:43 PM, Roger Ineichen d...@projekt01.ch wrote: Now we only need to find out how to write an z3c.autoexlude and a z3c.autooverride library ;-) :) Just so that this doesn't get misinterpreted, autoinclude includes packages just like manual include statements do underneath, so there should be no incompatibility with the exclude directive at all. You can override autoincluded packages just like you'd override any included package. In addition there's an includeDependenciesOverrides directive which can include overrides automatically if you wish to do that. If a package uses z3c.autoinclude to include its dependencies there'll be no difference in what you can do concerning overrides or exclusion. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: merge zc.configuration's exclude directiveinto zope.configuration.
Hi Martijn Betreff: Re: [Zope-dev] Proposal: merge zc.configuration's exclude directiveinto zope.configuration. Hi there, On Thu, Feb 26, 2009 at 12:43 PM, Roger Ineichen d...@projekt01.ch wrote: Now we only need to find out how to write an z3c.autoexlude and a z3c.autooverride library ;-) :) Just so that this doesn't get misinterpreted, autoinclude includes packages just like manual include statements do underneath, so there should be no incompatibility with the exclude directive at all. You can override autoincluded packages just like you'd override any included package. In addition there's an includeDependenciesOverrides directive which can include overrides automatically if you wish to do that. If a package uses z3c.autoinclude to include its dependencies there'll be no difference in what you can do concerning overrides or exclusion. I was just kiding as you saw. But this sounds very good to me since it has no other side effects! Thanks Roger Ineichen Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope.pipeline proposal
Chris McDonough wrote: [snip] While I think that would be a good thing, I do want to mention that it's not really the point of the whatsitdoing benchmark. Right, agreed. I think it's more important to make the Zope Framework more comprehensible than it is to improve its performance. Its performance is already fine for many purposes and it'll be much easier to improve once the structure is more comprehensible anyway. We have currently two efforts going on to increase comprehensibility of the Zope Framework: * cutting away code that isn't needed or is unnecessarily pulled in. This is the dependency refactoring work. * Shane's zope.pipeline work. I'm pretty pleased we have all of this going, as long as we keep it up. :) That we need to clean up the framework became clear to me much before Chris started pointing out things in the whatsitdoing benchmark though, but earlier discussions about Repoze (in particular with Tres at DZUG last september) did help shape my ideas. Repoze stuff typically tries to simplify each component in the set of components used to service a goal, sometimes at the expense of at least some backwards compatibility or excessive configurability. On the other hand, Zope3 and Grok tend to keep backwards compatibility and configurability sometimes at the expense of verbosity and extra runtime expense. They are just somewhat different goals. Repoze stuff therefore has the major advantage of not needing to carry around 6-10 years of backwards compatibility baggage; it owes any 20-20 hindsight in these cases of course directly to Zope. I do believe we can move the existing Zope Framework forward quite a bit in the right direction too. Perhaps we'll have to give up some backwards compatibility, but we can probably keep most of the code working. We haven't been afraid to break things occasionally with Grok but we've found that with good upgrade notes we can keep the pain to a minimum. This work should also result in more reusable components for Repoze and more use of Repoze components within code that uses the Zope Framework (such as Grok), so that should make us all happy. :) Luckily we're not starting with a very bad situation here. We have the benefit that the Zope Framework (and Grok) are made out of pieces that are at least *somewhat* tractable and replaceable. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: merge zc.configuration's exclude directive into zope.configuration.
On Feb 26, 2009, at 5:26 AM, Dan Korostelev wrote: Hi there. The exclude directive provided by zc.configuration package is easy to use and straightforward. I think it's used almost in every zope-based application setup. Its implementation is very small and fits great in zope.configuration's standard directives. So I'd like to propose to move it to zope.configuration and make it always available for ZMCL files, just like the include directive, so people would'nt need to install extra package and include an extra meta.zcml file before being able to use it. If noone objects, I'd like to do that That would be great. Thanks. and make the exclude directive from zc.configuration point to the zope.configuration's implementation making the original place deprecated (however I guess the whole zc.configuration package should't be deprecated as it's intended to be a common place for configuration extensions, even if it has only one directive now). Jim, if you're fine with that, can you please give me rights for zc.configuration on PYPI, my user name is nadako. Done, although, if you were me, you'd just leave it. :) Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: merge zc.configuration's exclude directive into zope.configuration.
2009/2/26 Jim Fulton j...@zope.com: and make the exclude directive from zc.configuration point to the zope.configuration's implementation making the original place deprecated (however I guess the whole zc.configuration package should't be deprecated as it's intended to be a common place for configuration extensions, even if it has only one directive now). Jim, if you're fine with that, can you please give me rights for zc.configuration on PYPI, my user name is nadako. Done, although, if you were me, you'd just leave it. :) Thanks. I think we need to make people know that they don't need this package anymore if they are looking for a way to exclude configuration. -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: merge zc.configuration's exclude directive into zope.configuration.
On Thu, Feb 26, 2009 at 7:07 AM, Martijn Faassen faas...@startifact.com wrote: Hey, On Thu, Feb 26, 2009 at 12:43 PM, Dan Korostelev nad...@gmail.com wrote: Yep, I know about z3c.autoinclude, but I don't like it, as it makes things more implicit and it also Yes, automation makes things more implicit. This is *not* an argument that can be used against any and all automation. An explicit includeDependencies directive will include the configure.zcml and meta.zcml of packages that are dependencies of that package. You make less mistakes this way (and it's very common to make the mistake to forget inclusion of some ZCML). It's also pretty rare to want to do otherwise in my experience (and there's always the exclude directive). I'd also argue auto-inclusion can actually help guard against dependency bugs, such as cases where a package tries to include ZCML it doesn't depend on (and works because some other package makes the dependency installed). +1 on Martijn's points (unsurprisingly, as I'm one of his co-authors on autoinclude ;) I'll also add that z3c.autoinclude tries very hard to log its actions in an easily traceable way, and I've been trying to build in more debugging tools as well. slows down startup time for applications that uses many eggs. When claims like that are made, I'd like to see measurements that demonstrate significant slowdowns during startup. Undoubtedly more code is excuted than when you write out 'include' directives manually, but is the slowdown actually measurable? I've heard this claim before and I'd also love to see some measurements. I haven't really had the time to do any myself, and in my experience z3c.autoinclude hasn't slowed things down enough to bother me. But I may have an unusually high tolerance for slow-moving code. :) The slowest code in z3c.autoinclude is well isolated and is tested for many edge cases, and I'm pretty sure there are obvious optimizations that can be made without even rewriting it. So improving the execution speed should be quite easy and safe; it just hasn't been a priority for me, and I'd prefer to get some measurements before trying to tweak it. I'd like to see an option for packages that are using z3c.autoinclude to make autoincluding conditional, so those who doesn't like it or needs more control could just turn it off. That's asking for a feature that other packages that *don't* use autoinclude don't support! You lose control as soon as you include a package's configure.zcml. There's no difference with non-auto-inclusion here; [snip] That's true on paper, but in practice z3c.autoinclude's *indirection* does make a difference when you're just trying to debug what's going on. At any rate, the next release of z3c.autoinclude will provide this feature, through environment variables: http://lists.plone.org/pipermail/framework-team/2009-February/002690.html Regards, Ethan ___ 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] [Checkins] SVN: z3c.pagelet/trunk/src/z3c/pagelet/tests.py Reenable z3c.pt tests, breaking tests again.
Can someone who is familiar with z3c.pt check this out, please? It
looks like the z3c.pt.expressions.ContentProviderTraverser somehow
receives wrong context/request/view objects.
Also, the ContentProviderTraverser should fire the BeforeUpdateEvent
before updating the content provider. And what about ITALNamespaceData
support? The contentprovider support won't be full without these
things.
2009/2/26 Dan Korostelev nad...@gmail.com:
Log message for revision 97320:
Reenable z3c.pt tests, breaking tests again.
Changed:
U z3c.pagelet/trunk/src/z3c/pagelet/tests.py
-=-
Modified: z3c.pagelet/trunk/src/z3c/pagelet/tests.py
===
--- z3c.pagelet/trunk/src/z3c/pagelet/tests.py 2009-02-26 16:54:30 UTC (rev
97319)
+++ z3c.pagelet/trunk/src/z3c/pagelet/tests.py 2009-02-26 17:02:59 UTC (rev
97320)
@@ -94,9 +94,7 @@
),
DocFileSuite('zcml.txt', setUp=setUp, tearDown=tearDown,
optionflags=doctest.NORMALIZE_WHITESPACE|doctest.ELLIPSIS,),
- ) for setUp in (setUpZPT, ))
- #) for setUp in (setUpZPT, setUpZ3CPT, ))
- # XXX: z3c.pt's provider expression is currently broken
+ ) for setUp in (setUpZPT, setUpZ3CPT, ))
return unittest.TestSuite(itertools.chain(*tests))
--
WBR, Dan Korostelev
___
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 )
