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 <a...@zitc.de > 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
