[Framework-Team] PLIP #247 ready for review (I think)

Andreas Zeidler 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,

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 <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  
> 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  

> 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  

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? :)



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...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20090205/53cb86f6/attachment.sig>

More information about the Framework-Team mailing list