poly check --strict false positive for a pytest plugin

$ poly check --strict
🔎 Is `e2e_test` needed in `e2e_test_base_project`?

where e2e_test_base_project is a project that runs e2e tests implemented on top of pytest.
It uses custom ns.e2e_test pytest plugin that is defined as a polylith component
(just some shared pytest fixtures between different e2e test projects).

The project does not import ns.e2e_test code explicitly. It is done by pytest itself, triggered by:

pytest_plugins = [
    "ns.e2e_test",
]

in conftest.py inside e2e_test_base polylith base which is the base for the e2e_test_base_project project.

Is there a way to suppress the poly check warning?

@zed

Hi @zed, is the component added as a brick in the project? If it's not used as a brick in the code then maybe it can be added to the project in a different way? This is how you can do it in Hatch.

As an alternative, you could do an import of it in code, and silence the linter with an "ignore".

Yes, ns/e2e_test is added as a brick to e2e_test_base_project.
If I remove it from the .bricks section, I get:

ImportError: Error importing plugin "ns.e2e_test": No module named 'ns.e2e_test'

The traceback shows that pytest uses the ordinary builtin
__import__
function
to import it.

I've considered the explicit dummy import ns.e2e_test but it might
mess with pytest's expected order (first it loads all conftest and
only then pytest_plugins recursively) and therefore it might have
unintended side-effects.

I've tried:

[tool.hatch.build.targets.sdist]
include = [
    "../../components/ns/e2e_test/"
]

but it does not include anything -- likely, because the path is outside the project root.

force-include
makes the files available in the distribution:

[tool.hatch.build.targets.sdist.force-include]
"../../components/ns/e2e_test/" = "ns/e2e_test"

but it does not fix the import error unless

[tool.polylith.bricks]
"../../components/ns/e2e_test/" = "ns/e2e_test"

is also present. It reintroduces the warning from poly check.

As a workaround, I use the explicit import (no side-effects so far in my case):

import ns.e2e_test   # noqa: F401

I'll think about if there's a simple way to solve this with the tooling, I think your use case should be supported.

Other: This should only happen when running the check command in --strict mode. Maybe you want to keep doing that, but it is also an alternative to just run poly check.

How do you run the tests, and how does the project fit in? I would like to reproduce this problem. I have the test dependencies in the root pyproject.toml, and run the tests in the virtual environment created for the repo root. If I understand it correctly, you have a Polylith project that contains tests?

There are 2 main ways to run the tests:

Using monorepo's virtualenv environment during developement of the tests themselves
Using project (projects/e2e_test_base_project) specific
virtualenv environment (or as uv tool install-ed version).

In both cases, the same command may be used (from different working directories):

uv run python -m ns.e2e_test_base

It picks up the desired venv automatically.

There is no issue with importing ns.e2e_test in the monorepo's
virtualenv because the development environment (repo's /pyproject.toml)
depends on all bricks including ns/e2e_test.

There is import error if ns/e2e_test is removed from the
project-specific (projects/e2e_test_base_project/pyproject.toml)
[tool.polylith.bricks] section.

I've made a mistake in the previous comment. force-include does help
with the import error too i.e., it is a viable workaround option. The
issue was in the interaction between uv run and
uv-dynamic-versioning for the project.

[build-system]
requires = ["hatchling", "hatch-polylith-bricks", "uv-dynamic-versioning"]
build-backend = "hatchling.build"

Great that using force-include works, and thank you for explaining more about your setup! I think it makes sense that the tool reports on the unused brick in --strict mode. That's also only an information to highlight that bricks could be removed from the project. I see a possible "skip" or "ignore" option or config, but I think that could cause other problems if forgetting to update configuration. Also, the poly check command won't exit with a fail code as with missing bricks or deps.

I was thinking about what can be done in the pytest files (such as conftest.py). Would this work? (I haven't tested this out, just an idea)

from ns import e2e_test

pytest_plugins = [e2e_test.__name__]

At the moment, I've settled on keeping ns/e2e_test as a brick and modifying conftest.py:

if False:
    # dummy import to silence `poly check --strict` warning
    import ns.e2e_test  # noqa: F401

 pytest_plugins = [
     "ns.e2e_test",
 ]

It makes both pytest and poly check happy. No import at runtime -- no undesirable side-effects.

e2e_test_base_project continues to be dependent on ns/e2e_test brick (good).

I've might have been too hasty with the force-include version. uv build . packages ns/e2e_test files but it does not translate into
working uv run python -m ns.e2e_test_base command in
projects/e2e_test_base_project dir in a clean environment (uv tool install-ed version works though).

Nice! I'll transfer this to a Q&A discussion, to keep it as documentation.

Navigation Menu

Repository navigation

`poly check --strict` false positive for a pytest plugin #400

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

poly check --strict false positive for a pytest plugin #400

Description

Activity

DavidVujic commented on Nov 14, 2025

zed commented on Nov 14, 2025

DavidVujic commented on Nov 14, 2025

DavidVujic commented on Nov 15, 2025

zed commented on Nov 15, 2025

DavidVujic commented on Nov 15, 2025

DavidVujic commented on Nov 15, 2025

zed commented on Nov 16, 2025

DavidVujic commented on Nov 16, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

`poly check --strict` false positive for a pytest plugin #400