[Framework-Team] PLIP #247 ready for review (I think)
az at zitc.de
Thu Feb 5 20:29:40 UTC 2009
On Feb 5, 2009, at 6:35 PM, Ethan Jucovy wrote:
> Hey Andi,
> 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 <az at 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
> > a "Duplicate entry point" error in `easy_install`. reading the
> > "target = plone, grok" isn't supported either. seeing that
> grok is
> > already actively using the package i would imagine that
> > multiple "base packages" (or projects) does make sense,
> though. adding
> > such support would be a definite plus, imho, and should also be
> > 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
> 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
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
+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? :)
zeidler it consulting - http://zitc.de/ - info at 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
More information about the Framework-Team