Re: [Framework-Team] PLIP #247 ready for review (I think)
On Sun, Jan 18, 2009 at 8:48 PM, Israel Saeta Pérez wrote: > On Sat, Jan 17, 2009 at 2:37 AM, Ethan Jucovy wrote: > >> >> Some of the things that people have said ought to be discussed about PLIP# >> 247 are: >> 1) impact on server startup time >> 2) implications for test environments >> 3) stabilizing and releasing a new version of z3c.autoinclude >> 4) debugging tools/APIs for z3c.autoinclude >> * 5) documentation and/or code generation templates to explain the entry >> point for plugin authors* >> >> I'll begin working on #3 immediately, since there's plenty I can do there >> while discussion is still happening. >> >> Please let me know if there's anything else I'll need to submit for the >> PLIP's review. >> > > I'm not a member of the Framework Team so this is not mandatory for the > PLIP's review, but as a member of the Documentation Team I would > appreciate number (5). > > Something like "Before, we did this to accomplish this task. Now, we can do > that.", as Wichert (?) suggested, so we would be able to find and update > affected docs easily. > > Thanks in advance! > The buildout manual has been updated (but updates are still private) to reflect this new feature: http://plone.org/documentation/tutorial/buildout/copy_of_creating-a-new-package See the new "Automate ZCML loading for your package section". I would appreciate any review input since I'm not sure I've got it right. Thanks! -- israel Documentation Team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #247 ready for review (I think)
On Feb 7, 2009, at 12:56 AM, Ethan Jucovy wrote: On Thu, Feb 5, 2009 at 3:37 PM, Andreas Zeidler wrote: On Feb 5, 2009, at 9:29 PM, Andreas Zeidler wrote: i noticed that. in fact, i was trying to figure out how the assigned value ("plone") ended up in `module_name`. i ended up looked at the entry point's (the one you get from `pkg_resources.iter_entry_points`) `__dict__`, assuming that some magic in `pkg_resources` would translate the "target" to be meant as the module's name. but apparently all given value end up as `module_name` in the dict. i suppose i should have had a closer look at entry point definitions first. Ah, yeah, a single entry point basically models a dictionary entry: `module_name` is (part of) the entry point's "value", which is imported as a Python object; `name` is the "key". i was missing that info initially, but figured as much after a bit... thanks for clarifying it again, though. Perhaps z3c.autoinclude could check if `os.environ.has_key('Z3C_AUTOINCLUDE_DISABLED')` and the test runner and/or a buildout option could set that environment variable? yep, also +1. after all, that's exactly what environment variable are for, aren't they? :) OK, z3c.autoinclude trunk as of r96193 checks for 'Z3C_AUTOINCLUDE_PLUGINS_DISABLED' and 'Z3C_AUTOINCLUDE_DEPENDENCIES_DISABLED' in the environment. great. just one more tiny little suggestion: how about catching the key error in the `enable_*` function, so people can use it unconditionally (i.e. without consulting `dependencies_disabled` first)? $ ./bin/zopepy >>> from z3c.autoinclude.api import enable_dependencies >>> enable_dependencies() Traceback (most recent call last): [...] KeyError: 'Z3C_AUTOINCLUDE_PLUGINS_DISABLED' n/p, none of this has been too time-consuming yet :) :) thanks for the update, ethan. i'm changing my vote to +1. cheers, andi -- zeidler it consulting - http://zitc.de/ - i...@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.2.1 released! -- http://plone.org/products/plone/ PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #247 ready for review (I think)
On Thu, Feb 5, 2009 at 3:37 PM, Andreas Zeidler wrote: > On Feb 5, 2009, at 9:29 PM, Andreas Zeidler wrote: >> i noticed that. in fact, i was trying to figure out how the assigned value >> ("plone") ended up in `module_name`. i >> ended up looked at the entry point's (the one you get from >> `pkg_resources.iter_entry_points`) `__dict__`, assuming >> that some magic in `pkg_resources` would translate the "target" to be meant >> as the module's name. but apparently >> all given value end up as `module_name` in the dict. i suppose i should >> have had a closer look at entry point definitions first. Ah, yeah, a single entry point basically models a dictionary entry: `module_name` is (part of) the entry point's "value", which is imported as a Python object; `name` is the "key". So an entry point "fleem = my.app.module:func" looks like {{{ >> ep EntryPoint.parse('fleem = my.app.module:func') >> ep.name 'fleem' >> ep.module_name ''my.app.module' >> ep.load() # basically `from my.app.module import func` }}} The entry point object also has a reference to the egg (distribution) that provides it. That's just about all they are, it's simpler than the pkg_resources docs make them sound. :) >> yes, [using an arbitrary entry point name instead of `target`] works. in >> any case this should be documented, though. Yeah, I'll work on this over the weekend. The docs in general need some cleaning up. >>> Perhaps z3c.autoinclude could check if >>> `os.environ.has_key('Z3C_AUTOINCLUDE_DISABLED')` and the test runner and/or >>> a buildout option could set that environment variable? >> >> yep, also +1. after all, that's exactly what environment variable are for, >> aren't they? :) OK, z3c.autoinclude trunk as of r96193 checks for 'Z3C_AUTOINCLUDE_PLUGINS_DISABLED' and 'Z3C_AUTOINCLUDE_DEPENDENCIES_DISABLED' in the environment. > i forgot to mention that it'd be great if you could try to work these out > until some time next week. technically the revision deadline is this > saturday, of course, but since my review was several days late, i think it's > only fair to still grant you a full week to address these issues. i hope the > delay doesn't cause too many inconveniences and you'll find the time it > takes... n/p, none of this has been too time-consuming yet :) Thanks, Ethan ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #247 ready for review (I think)
On Feb 5, 2009, at 9:29 PM, Andreas Zeidler wrote: [...snip...] yes, that works. in any case this should be documented, though. [...snip again...] Perhaps z3c.autoinclude could check if `os.environ.has_key('Z3C_AUTOINCLUDE_DISABLED')` and the test runner and/or a buildout option could set that environment variable? yep, also +1. after all, that's exactly what environment variable are for, aren't they? :) i forgot to mention that it'd be great if you could try to work these out until some time next week. technically the revision deadline is this saturday, of course, but since my review was several days late, i think it's only fair to still grant you a full week to address these issues. i hope the delay doesn't cause too many inconveniences and you'll find the time it takes... cheers, andi -- zeidler it consulting - http://zitc.de/ - i...@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.2rc1 released! -- http://plone.org/products/plone/ PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #247 ready for review (I think)
On Feb 5, 2009, at 6:35 PM, Ethan Jucovy wrote: Hey Andi, hi ethan, Thanks for the review. thanks for the quick reply! :) Again I'll have to be a bit brief, this time because I'm about to get on a plane. :) But I figured I may as well give some quick replies to keep the conversation going. much appreciated. oh, and sorry for the late review, btw. i'm not sure you saw my message yesterday, but unfortunately a few things kept me from doing it earlier (lack of sleep amongst them :)). Let me know if I should be putting these comments in SVN or on http://plone.org/products/plone/roadmap/247 instead of//as well as replying on-list, BTW. i guess the list is fine, as interested parties can still read the entire discussion in the archives, for example by following the link i put on the PLIP page. you may of course also answer there or link to your answer here. i don't think we have any strict policy in place about this. :) At http://dev.plone.org/plone/changeset/24863, Andreas Zeidler > wrote: > * one issue i was wondering about is how to "target" multiple base packages >for the plugin case. adding an additional "target = ..." line yields >a "Duplicate entry point" error in `easy_install`. reading the code >"target = plone, grok" isn't supported either. seeing that grok is >already actively using the package i would imagine that supporting >multiple "base packages" (or projects) does make sense, though. adding >such support would be a definite plus, imho, and should also be rather >simple to do. This is actually already a hidden feature. ;) The entry point name ("target") is purely convention; it's not used at all in the code. i noticed that. in fact, i was trying to figure out how the assigned value ("plone") ended up in `module_name`. i ended up looked at the entry point's (the one you get from `pkg_resources.iter_entry_points`) `__dict__`, assuming that some magic in `pkg_resources` would translate the "target" to be meant as the module's name. but apparently all given value end up as `module_name` in the dict. i suppose i should have had a closer look at entry point definitions first. So {{{ entry_points=""" [z3c.autoinclude.plugin] morx = plone bar = mygrok.app """ }}} yes, that works. in any case this should be documented, though. Big +1 on considering the testing complications. (Though in my limited experience I've actually found that any of my tests that break as a result of z3c.autoinclude's "unpredictable" ZCML inclusion are badly isolated tests anyway.) well, i was thinking of a debug session where some tests where failing after LinguaPlone had been added to the buildout. i'm not entirely sure anymore if i had already added it to the buildout (zcml-wise) or if the module was loaded by the testrunner thereby activating some monkey-patches. but you're right, that might also qualify as bad test isolation, but every little bit that helps making this easier is much appreciated (and i know not just by me :)). My gut feeling is that I'd rather keep logic like what to do in test runs, or for that matter what a test run is, out of z3c.autoinclude though. +1, of course. that wouldn't make sense, imho. there are too many different testrunners for one, and there will probably be others in the future. "knowing" them all is certainly not something `z3c.autoinclude` should attempt. Perhaps z3c.autoinclude could check if `os.environ.has_key('Z3C_AUTOINCLUDE_DISABLED')` and the test runner and/or a buildout option could set that environment variable? yep, also +1. after all, that's exactly what environment variable are for, aren't they? :) cheers, andi -- zeidler it consulting - http://zitc.de/ - i...@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.2rc1 released! -- http://plone.org/products/plone/ PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #247 ready for review (I think)
Hey Andi, Thanks for the review. Again I'll have to be a bit brief, this time because I'm about to get on a plane. :) But I figured I may as well give some quick replies to keep the conversation going. Let me know if I should be putting these comments in SVN or on http://plone.org/products/plone/roadmap/247instead of//as well as replying on-list, BTW. At http://dev.plone.org/plone/changeset/24863, Andreas Zeidler wrote: > * one issue i was wondering about is how to "target" multiple base packages >for the plugin case. adding an additional "target = ..." line yields >a "Duplicate entry point" error in `easy_install`. reading the code >"target = plone, grok" isn't supported either. seeing that grok is >already actively using the package i would imagine that supporting >multiple "base packages" (or projects) does make sense, though. adding >such support would be a definite plus, imho, and should also be rather >simple to do. This is actually already a hidden feature. ;) The entry point name ("target") is purely convention; it's not used at all in the code. So {{{ entry_points=""" [z3c.autoinclude.plugin] morx = plone bar = mygrok.app """ }}} ought to do what you describe. The only reason we used the "target" convention at all is to make it read well and to keep the documentation simpler. > * as for `david's and my reservations`__ wrt testing i'd like to add >that this package only automates the otherwise manually added >loading of zcml for additional packages in your buildout. iow, it >doesn't make a difference compared to the situation we have right >now: if you add a package to your buildout it's zcml will be loaded >by the ZCML layer anyway, even if you only run specific tests for >some other, unrelated package. so shipping with `z3c.autoinclude` >doesn't change or make this any worse. > >however, imho always loading essentially all zcml contained in your >buildout is a huge problem and should be fixed at some point. otoh >not doing so might prevent you from finding possible conflicts or >otherwise bad interactions between your packages more quickly. so i >suppose ideally it should be an option to the testrunner, but disabled >by default. > >now if we start depending on `z3c.autoinclude` i think this will get >harder to fix in the future. right now the additional packages are >pulled in by your buildout, but with this change plone itself will handle >this. so the zcml loading `z3c.autoinclude` should at least be made >conditional. that way you could simply disable `z3c.autoinclude` (i'm >thinking of something like ``eggs -= z3c.autoinclude` here) and prevent >everything being loaded. this change could then even turn out to be >helpful wrt fixing the above mentioned issue, since `z3c.autoinclude` >alone could be changed to not trigger zcml loading during test runs. Big +1 on considering the testing complications. (Though in my limited experience I've actually found that any of my tests that break as a result of z3c.autoinclude's "unpredictable" ZCML inclusion are badly isolated tests anyway.) My gut feeling is that I'd rather keep logic like what to do in test runs, or for that matter what a test run is, out of z3c.autoinclude though. Perhaps z3c.autoinclude could check if `os.environ.has_key('Z3C_AUTOINCLUDE_DISABLED')` and the test runner and/or a buildout option could set that environment variable? Thanks again, Ethan ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #247 ready for review (I think)
On Jan 17, 2009, at 2:37 AM, Ethan Jucovy wrote: Hello, hi ethan, I've implemented PLIP #247, Automate ZCML Loading for Plone Plugins (http://plone.org/products/plone/roadmap/247 ) and committed a review buildout here: https://svn.plone.org/svn/plone/review/plip247-automate-plugin-zcml for your review. i've added my review notes in http://dev.plone.org/plone/changeset/ 24863 (and r24864). for now i'm +0, but this can be fixed quite easily... :) cheers, andi -- zeidler it consulting - http://zitc.de/ - i...@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.2rc1 released! -- http://plone.org/products/plone/ PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #247 ready for review (I think)
On Fri, Jan 30, 2009 at 21:00, Ethan Jucovy wrote: > * after seeing your reply, I tried running the tests in the PLIP buildout's > environment with `bin/instance test -s z3c.autoinclude` and did see failures > * i've now fixed them Yay! :-) > * can you reconfirm that the failures you saw were from utils.txt? the ones > i saw were from plugin.txt (though the assertion that was triggered was > indeed the alarming one in utils.py) > * briefly, the problem was that the "foo" module in the demonstration > package i provided collided with another "foo" module that's installed in > z3c.autoinclude's test environment > (z3c.autoinclude/src/z3c/autoinclude/tests/FooPackage is the egg). moral: > namespaces are indeed a good idea. :) i've renamed the demo package to > plip247.foo and will also namespace z3c.autoinclude's test packages before > the next release so this doesn't happen again I've updated the foo.cfg buildout config to reflect this. > * the reason that assertion was so alarming and vague is because, when i > wrote the code, i had no idea what sort of situation could possibly trigger > it. so i figured i might as well throw in an assertion, even if // because i > couldn't imagine what its failure would mean. now that it's actually popped > up i think i understand it: it's asserting that no more than one > non-empty-virtual-namespace-module named "foo" (for any string "foo") will > be importable simultaneously. i'll make the assertion less alarming and > more informative as soon as i figure out a concise way to say that. Great! It's a good idea to explicitly warn about this. > * do the tests pass for you now in a fresh buildout // if you svn up and > re-install the "foo" demo package? again, they are passing for me now in > this environment, let me know if you're seeing different failures. The tests now all pass, I've upgraded my review verdict to a +1. :-) > Thanks again for taking the time to look at this, I really appreciate all of > your notes (and the buildout help!) & I'll try to be as responsive as I > possibly can. np! Thanks for your hard work on implementing the PLIP! -- Martijn Pieters ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #247 ready for review (I think)
I just spent three hours writing a detailed email explaining the situation, but gmail seems to have completely swallowed it, drafts and all, when I hit "send". I'm travelling right now and have very limited internet connectivity here, so I'm just going to try to briefly summarize my original reply; if further clarification is needed, let me know and I'll provide more information as soon as I can. Sorry to be so terse, this gmail accident is just making me *really* grumpy. :) * the test failures are on the trunk of z3c.autoinclude; releases have been stable and are tested on multiple OSes and python environments before I cut them. i'll continue to be careful about this in the future. * the tests pass (for me at least) in the environment created by z3c.autoinclude's standalone buildout -- which is the only way I thought to run them before submitting the plip * after seeing your reply, I tried running the tests in the PLIP buildout's environment with `bin/instance test -s z3c.autoinclude` and did see failures * i've now fixed them * can you reconfirm that the failures you saw were from utils.txt? the ones i saw were from plugin.txt (though the assertion that was triggered was indeed the alarming one in utils.py) * briefly, the problem was that the "foo" module in the demonstration package i provided collided with another "foo" module that's installed in z3c.autoinclude's test environment (z3c.autoinclude/src/z3c/autoinclude/tests/FooPackage is the egg). moral: namespaces are indeed a good idea. :) i've renamed the demo package to plip247.foo and will also namespace z3c.autoinclude's test packages before the next release so this doesn't happen again * the reason that assertion was so alarming and vague is because, when i wrote the code, i had no idea what sort of situation could possibly trigger it. so i figured i might as well throw in an assertion, even if // because i couldn't imagine what its failure would mean. now that it's actually popped up i think i understand it: it's asserting that no more than one non-empty-virtual-namespace-module named "foo" (for any string "foo") will be importable simultaneously. i'll make the assertion less alarming and more informative as soon as i figure out a concise way to say that. * do the tests pass for you now in a fresh buildout // if you svn up and re-install the "foo" demo package? again, they are passing for me now in this environment, let me know if you're seeing different failures. Thanks again for taking the time to look at this, I really appreciate all of your notes (and the buildout help!) & I'll try to be as responsive as I possibly can. thanks, ethan On Sun, Jan 25, 2009 at 9:31 AM, Martijn Pieters wrote: > On Sat, Jan 17, 2009 at 02:37, Ethan Jucovy > wrote: > > I've implemented PLIP #247, Automate ZCML Loading for Plone Plugins > > (http://plone.org/products/plone/roadmap/247) and committed a review > > buildout here: > > https://svn.plone.org/svn/plone/review/plip247-automate-plugin-zcml > > for your review. > > I have started my review. > > To my dismay, however, the z3c.autoinclude package has several test > failures. I understand that this package is also being used by the > Grok project, and it appears to work as advertised, but test failures > is not a good sign of package quality. For example, utils.txt somehow > triggers an assert on line 99 in utils.py, which has a somewhat > distressing comment: > > assert len(non_namespaced_dists) == 1 ### we really are in > trouble if we get into a situation with more than one > > Could you comment on the state of these failures? > > > The buildout is branched from the 3.3 review bundle > > buildout based on buildout.eggtractor, which automatically generates ZCML > > slugs for development packages and puts them in > parts/instance/etc/package- > > includes. Since the purpose of PLIP 247 is to automate ZCML loading, > those > > automatically generated ZCML slugs should be removed. I've hardly ever > used > > buildout so I'm not sure how to change that behavior -- sorry about that; > > I'll change it if I can figure out how. > > Simply *not* use buildout.eggtractor; you only have 3 eggs in this > buildout, add them to the develop, eggs and zcml lines and Bob's your > uncle. Alternatively, just set tractor-autoload-zcml to false, which > you did. > > -- > Martijn Pieters > ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #247 ready for review (I think)
On Sat, Jan 17, 2009 at 02:37, Ethan Jucovy wrote: > I've implemented PLIP #247, Automate ZCML Loading for Plone Plugins > (http://plone.org/products/plone/roadmap/247) and committed a review > buildout here: > https://svn.plone.org/svn/plone/review/plip247-automate-plugin-zcml > for your review. Here is my full verdict, as committed to the bundle readme: I've updated the buildout to not use buildout.eggtractor; you already had disabled it's zcml autoloading but didn't add Products.CMFPlone to the zcml line. Not using buildout.eggtractor at all is a better idea here, however. I've also added a foo.cfg buildout configuration to test the (very nice!) demonstration package. Just run bin/buildout -c foo.cfg to have the foo package included. After these changes, the z3c.autoinclude package appears to work as advertised. However, when running the z3c.autoinclude tests I see test failures, which worries me. I understand that the package is being used by Grok as well, and this PLIP merely covers the inclusion of the package into Plone, but I'd like to see some comments about what these test failures are about. Until I see comments that alleviate my concerns about the test failures, I'm giving this PLIP a +0. -- Martijn Pieters ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #247 ready for review (I think)
On Sat, Jan 17, 2009 at 02:37, Ethan Jucovy wrote: > I've implemented PLIP #247, Automate ZCML Loading for Plone Plugins > (http://plone.org/products/plone/roadmap/247) and committed a review > buildout here: > https://svn.plone.org/svn/plone/review/plip247-automate-plugin-zcml > for your review. I have started my review. To my dismay, however, the z3c.autoinclude package has several test failures. I understand that this package is also being used by the Grok project, and it appears to work as advertised, but test failures is not a good sign of package quality. For example, utils.txt somehow triggers an assert on line 99 in utils.py, which has a somewhat distressing comment: assert len(non_namespaced_dists) == 1 ### we really are in trouble if we get into a situation with more than one Could you comment on the state of these failures? > The buildout is branched from the 3.3 review bundle > buildout based on buildout.eggtractor, which automatically generates ZCML > slugs for development packages and puts them in parts/instance/etc/package- > includes. Since the purpose of PLIP 247 is to automate ZCML loading, those > automatically generated ZCML slugs should be removed. I've hardly ever used > buildout so I'm not sure how to change that behavior -- sorry about that; > I'll change it if I can figure out how. Simply *not* use buildout.eggtractor; you only have 3 eggs in this buildout, add them to the develop, eggs and zcml lines and Bob's your uncle. Alternatively, just set tractor-autoload-zcml to false, which you did. -- Martijn Pieters ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #247 ready for review (I think)
On Sat, Jan 17, 2009 at 2:37 AM, Ethan Jucovy wrote: > > Some of the things that people have said ought to be discussed about PLIP > #247 are: > 1) impact on server startup time > 2) implications for test environments > 3) stabilizing and releasing a new version of z3c.autoinclude > 4) debugging tools/APIs for z3c.autoinclude > * 5) documentation and/or code generation templates to explain the entry > point for plugin authors* > > I'll begin working on #3 immediately, since there's plenty I can do there > while discussion is still happening. > > Please let me know if there's anything else I'll need to submit for the > PLIP's review. > I'm not a member of the Framework Team so this is not mandatory for the PLIP's review, but as a member of the Documentation Team I would appreciate number (5). Something like "Before, we did this to accomplish this task. Now, we can do that.", as Wichert (?) suggested, so we would be able to find and update affected docs easily. Thanks in advance! -- israel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP #247 ready for review (I think)
Hello, I've implemented PLIP #247, Automate ZCML Loading for Plone Plugins ( http://plone.org/products/plone/roadmap/247) and committed a review buildout here: https://svn.plone.org/svn/plone/review/plip247-automate-plugin-zcml for your review. The buildout is branched from the 3.3 review bundle buildout based on buildout.eggtractor, which automatically generates ZCML slugs for development packages and puts them in parts/instance/etc/package-includes. Since the purpose of PLIP 247 is to automate ZCML loading, those automatically generated ZCML slugs should be removed. I've hardly ever used buildout so I'm not sure how to change that behavior -- sorry about that; I'll change it if I can figure out how. The changes in Plone itself (branched and pulled in with an svn:external) are pretty small: I added z3c.autoinclude as a dependency in setup.py, included z3c.autoinclude's meta.zcml from Products/CMFPlone/meta.zcml and added the directives to Products/CMFPlone/configure.zcml, meta.zcml and overrides.zcml. I've included a sample plugin package `foo` as an svn external in src/. If you install that package in your environment (by adding it to buildout.cfg's [develop] section for example -- though again the package-include slugs should be removed) its ZCML will be automatically detected and executed (from Products.CMFPlone's directives) when the zope server is started. The foo package has a README with more details. The implementation is currently using the unreleased trunk of z3c.autoinclude to allow the entry point spelling "target=plone" (as opposed to "target=Products.CMFPlone") and to allow three separate directives to load a plugin's meta.zcml, configure.zcml, and overrides.zcml. Some of the things that people have said ought to be discussed about PLIP #247 are: 1) impact on server startup time 2) implications for test environments 3) stabilizing and releasing a new version of z3c.autoinclude 4) debugging tools/APIs for z3c.autoinclude 5) documentation and/or code generation templates to explain the entry point for plugin authors I'll begin working on #3 immediately, since there's plenty I can do there while discussion is still happening. Please let me know if there's anything else I'll need to submit for the PLIP's review. Thanks, Ethan Jucovy ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team