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

[zed]

$ 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?

[DavidVujic]

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".

[zed]

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

[DavidVujic]

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.

[DavidVujic]

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?

[zed]

There are 2 main ways to run the tests:

1. Using monorepo's virtualenv environment during developement of the tests themselves
2. 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"

[DavidVujic]

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.

[DavidVujic]

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__]

[zed]

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).

[DavidVujic]

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