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