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

Ethan Jucovy ethan.jucovy at gmail.com
Fri Jan 30 20:00:06 UTC 2009


I just spent three hours writing a detailed email explaining the situation,
but gmail seems to have completely swallowed it, drafts and all, when I hit
"send".  I'm travelling right now and have very limited internet
connectivity here, so I'm just going to try to briefly summarize my original
reply; if further clarification is needed, let me know and I'll provide more
information as soon as I can.  Sorry to be so terse, this gmail accident is
just making me *really* grumpy. :)

 * the test failures are on the trunk of z3c.autoinclude; releases have been
stable and are tested on multiple OSes and python environments before I cut
them. i'll continue to be careful about this in the future.
 * the tests pass (for me at least) in the environment created by
z3c.autoinclude's standalone buildout -- which is the only way I thought to
run them before submitting the plip
 * after seeing your reply, I tried running the tests in the PLIP buildout's
environment with `bin/instance test -s z3c.autoinclude` and did see failures
 * i've now fixed them
 * can you reconfirm that the failures you saw were from utils.txt? the ones
i saw were from plugin.txt (though the assertion that was triggered was
indeed the alarming one in utils.py)
 * briefly, the problem was that the "foo" module in the demonstration
package i provided collided with another "foo" module that's installed in
z3c.autoinclude's test environment
(z3c.autoinclude/src/z3c/autoinclude/tests/FooPackage is the egg).  moral:
namespaces are indeed a good idea.  :) i've renamed the demo package to
plip247.foo and will also namespace z3c.autoinclude's test packages before
the next release so this doesn't happen again
 * the reason that assertion was so alarming and vague is because, when i
wrote the code, i had no idea what sort of situation could possibly trigger
it. so i figured i might as well throw in an assertion, even if // because i
couldn't imagine what its failure would mean. now that it's actually popped
up i think i understand it: it's asserting that no more than one
non-empty-virtual-namespace-module named "foo" (for any string "foo") will
be importable simultaneously.  i'll make the assertion less alarming and
more informative as soon as i figure out a concise way to say that.
 * do the tests pass for you now in a fresh buildout // if you svn up and
re-install the "foo" demo package?  again, they are passing for me now in
this environment, let me know if you're seeing different failures.

Thanks again for taking the time to look at this, I really appreciate all of
your notes (and the buildout help!) & I'll try to be as responsive as I
possibly can.

thanks,
ethan

On Sun, Jan 25, 2009 at 9:31 AM, Martijn Pieters <mj at zopatista.com> wrote:

> On Sat, Jan 17, 2009 at 02:37, Ethan Jucovy <ethan.jucovy at gmail.com>
> wrote:
> > I've implemented PLIP #247, Automate ZCML Loading for Plone Plugins
> > (http://plone.org/products/plone/roadmap/247) and committed a review
> > buildout here:
> >  https://svn.plone.org/svn/plone/review/plip247-automate-plugin-zcml
> > for your review.
>
> I have started my review.
>
> To my dismay, however, the z3c.autoinclude package has several test
> failures. I understand that this package is also being used by the
> Grok project, and it appears to work as advertised, but test failures
> is not a good sign of package quality. For example, utils.txt somehow
> triggers an assert on line 99 in utils.py, which has a somewhat
> distressing comment:
>
>   assert len(non_namespaced_dists) == 1          ### we really are in
> trouble if we get into a situation with more than one
>
> Could you comment on the state of these failures?
>
> > The buildout is branched from the 3.3 review bundle
> > buildout based on buildout.eggtractor, which automatically generates ZCML
> > slugs for development packages and puts them in
> parts/instance/etc/package-
> > includes.  Since the purpose of PLIP 247 is to automate ZCML loading,
> those
> > automatically generated ZCML slugs should be removed.  I've hardly ever
> used
> > buildout so I'm not sure how to change that behavior -- sorry about that;
> > I'll change it if I can figure out how.
>
> Simply *not* use buildout.eggtractor; you only have 3 eggs in this
> buildout, add them to the develop, eggs and zcml lines and Bob's your
> uncle. Alternatively, just set tractor-autoload-zcml to false, which
> you did.
>
> --
> Martijn Pieters
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20090130/9981546f/attachment.html>


More information about the Framework-Team mailing list