Rewrite hook attempts to rewrite namespace package

[jaraco]

As discovered in pypa/setuptools#1038, when the following is true:

• a plugin (such as backports.unittest_mock) is a namespace package,
• that namespace package is defined using the recommended pkg_util technique,
• that plugin is used by the test environment, and
• something in the test suite attempts to import another package in that namespace,

py.test will attempt to rewrite the namespace package module, which will cause errors in sandboxed environments where writing outside of the prescribed directory is disallowed.

It's not obvious to me that this is a bug in pytest, and I admit, the factors are highly specialized.

Still, since namespace packages using the pkg_resources technique don't cause pytest to rewrite that package, I'd like to consider if this issue can be addressed by pytest detecting and honoring these namespace packages and excluding them from needing rewriting.

I have a minimal test project I will be pushing shortly demonstrating the issue.

[RonnyPfannschmidt]

@jaraco i believe the actual issue is that the rewriter also tries to write to the __pycache__ folders

is there a cheap way to detect the setuptools sandbox so we can opt out of writing in such cases

[jaraco]

Yes, indeed. The rewriter is attempting to create the __pycache__ folder for the namespace package. And while I've filed an issue with pypa/python-packaging-user-guide regarding the expectation of namespace packages, it seems interesting if not pertinent that this issue doesn't occur when the package(s) in question are managed by pkg_resources.

I want to be cautious (if possible) not to overfit the solution to this symptom. That is, it's not obvious to me that the rewrite hook should silently fail if it finds itself unable to write to the pycache folder... that is, unless it makes sense to always silently fail if creating the cache files is optional.

More importantly, I'd like to answer the question - why is pytest marking these packages as needing rewrite and should it be more precise about what needs rewritten? For example, I can see how the inclusion of backports.unittest_mock (the package) might signal to pytest to rewrite backports.unittest_mock (the module as indicated in the pytest11 entry point), but should it also rewrite every package and module contained in the distribution package containing that plugin? Should that also extend to other distribution packages sharing a namespace with the plugin? That is, what's the value of rewriting backports for backports.ssl_match_hostname?

[jaraco]

I disabled the functionality for marking plugin files for rewrite, after which the test suite quickly revealed that #1920 captures why plugins need their imports rewritten.

I experimented with the idea of only marking for rewrite those modules specified by the plugins, so if the pytest11: ['myplugin = foo.bar'], only foo.bar would be marked for rewrite and not every file or package in the distribution package for that plugin. However, it seems the tests (specifically TestImportHookInstallation.test_installed_plugin_rewrite) are asserting that functionality not referenced by the entry point explicitly is implicitly rewritten. In that test, spamplugin is the module that's referenced in the entry point, but because that module also imports hampkg, that causes other pytest fixtures to be loaded.

This behavior strikes me as problemmatic, as it's relying on the bundling of behavior into a distribution package to determine when to rewrite, which would fail in a scenario where a plugin imports fixtures from another package:

• myplugin has a dependency on other_pkg.
• myplugin defines a pytest11 entry point but other_pkg does not: ['myplugin = myplugin.fixtures'].
• in the module myplugin.fixtures, it imports other_pkg.fixtures which defines additional fixtures.

In this scenario, when myplugin (and thus other_pkg) are installed, the fixtures from both packages will be made available, but only those in myplugin will be assert rewritten (because those in other_pkg aren't part of the myplugin distribution, the current heuristic for determining candidacy for rewrite).

I propose that pytest should instead change the spec such that:

• only those modules indicated in the pytest11 entry point will be rewritten.
• plugin authors should either specify using entry points all of the modules that should be rewritten or there should be another mechanism by which a package may explicitly declare other modules as being plugin-relevant modules that should be rewritten.

Such a change would prevent pytest from over-eagerly reaching into some packages (as it does with namespace packages such as backports.*) but also prevent pytest from failing to match relevant modules such as other_pkg in the hypothetical scenario above. It would also correct the secondary issue reported downstream.

Thoughts?

[jaraco]

Also to note, such an approach would make the code for rewrite candidacy dramatically simpler, like:

for ep in pkg_resources.iter_entry_points('pytest11'):
    hook.mark_rewrite(ep.module_name)) 

[jaraco]

is there a cheap way to detect the setuptools sandbox so we can opt out of writing in such cases

The short answer is no. The sandboxing happens in a setuptools.sandbox.DirectorySandbox class that is never exposed by name. One could keep a reference to os.mkdir early, and then when detecting for sandbox, compare os.mkdir to the saved reference and if they're different, bypass the writing of the pyc.

As I mentioned before, I feel uncomfortable with the idea of pytest specifically avoiding writing pycache files specifically when in a sandbox. Can the pytest assert rewrites work without writing pycache files? It's conceivable that pytest could catch and suppress a sandbox.SandboxViolation in that code and treat it like one of the other cases where cache files aren't written.

It seems there are a few things that pytest could do here:

• change rewrite behavior to be more selective and explicit about what is rewritten (proposed above).
• detect and ignore namespace packages when doing rewrites.
• provide a hook or ask setuptools to monkeypatch pytest to avoid the error.
• suppress these errors when encountered (adds complication between pytest and setuptools mainly for the purpose of setuptools' own tests).

Those are in my order of preference, although the first option is by far the most invasive. I'm open to other ideas also.

I've worked around the urgency of the issue by pinning to the old backports module, but that solution is only temporary.

I'll wait until others have time to absorb the considerations and recommend the preferred way forward for pytest.

[RonnyPfannschmidt]

Given your very detailed description, I believe we should catch the sandbox error

[asottile]

@jaraco do you happen to have a minimal reproduction? I'm curious if #5468 resolves this

[jaraco]

See the aforementioned repository pytest-dev/pytest-issue-2419. It has two branches, master which I created a couple of years ago, and alt-repro, which I created recently not realizing I already had a reproducer. I think the master is a more accurate capturing of the issue. Run it with tox -e py27 and you'll see the rewrite warning using the latest released pytest. You'll also see a failure message which I think has changed over time.

You can't use pytest master due to Python 2 incompatibility (and your patch excludes the possibility of a backport), so I'm not sure your patch is relevant.