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

[Ethan Jucovy]

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
<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.  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20090205/c6281b4f/attachment.html>