AttributeError: 'module' object has no attribute 'DemoLayer'

[Marius Gedminas]

Running the tests of all Zope 3.4 KGS packages makes the test runner abort with

AttributeError: 'module' object has no attribute 'DemoLayer'

in layer_from_name.

I've added some diagnostics in r89123 to zope.testing trunk and in r89132 to the 3.5 branch. That tells me the module in question is z3c.skin.pagelet.testing, but that package is hard to work with (no buildbot, and grepping for 'DemoLayer' finds nothing in trunk). If I disable the z3c.skin tests and retry the experiment, I get the same problem with z3c.etestbrowser. Now z3c.etestbrowser defines its test layer as

layer = functional.ZCMLLayer(
    os.path.join(os.path.split(__file__)[0], 'ftesting.zcml'),
    __name__, 'ETestBrowserLayer')

so if you try to import z3c.etestbrowser.tests and access z3c.etestbrowser.tests.ETestBrowserLayer, you'll get an AttributeError.

Reading the source code of the test runner enlightens me that this is a supported use case:

       Note that a name -> layer cache is maintained by name_from_layer
       to allow locating layers in cases where it would otherwise be
       impossible.

This is why, if you run the z3c.etestbrowser tests in isolation, you won't see any problems. Something is clearing the _layer_name_cache in the test runner.

Further testing reveals that something to be zope.app.twisted.ftp.tests, specifically, trial.txt. It imports zope.testing.testrunner and runs it inside a doctest. The testrunner runs in the same process and clears the _layer_name_cache global.

Simplest fix: remember the old cache and restore it, so that run_with_options becomes reentrant. It's a bit ugly (see the patch; the try/finally statement pushes everything to the right producing a hard-to-read diff).

[Marius Gedminas (mgedmin)]

Alternative ideas:

  1. Drop the support for unreferenceable layers and get rid of the layer name cache. Then fix all the modules that currently make use of this (mis)feature.

  2. Get rid of the global cache; instead use a local one and pass it around to functions that aren't methods and can't access it from self. Not doable in the 3.5 branch without a major refactoring; thankfully the trunk is refactored and this could be done there, I think.

I assume (1) will make someone unhappy, so I'm leaning towards option (2).

[Marius Gedminas (mgedmin)]

Fixed in the 3.5 branch in rev 89164.

[Marius Gedminas (mgedmin)]

Fixed in 3.5.4

[Marius Gedminas (mgedmin)]

So far I'm unable to reproduce the bug with zope.testing 3.6.0. I'm pretty sure the bug's still there, but I can't trigger it.

[Colin Watson (cjwatson)]

The zope.testing project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope.testing.