Currently, we have the runtime requirements in the default resolve and pytest and its requirements in a separate lock file. Previously, pants seemed to always have merged these two in order to execute the tests and the import inference seemed to have worked fine. Now with

unowned_dependency_behavior = "error"

we're seeing the following error:

UnownedDependencyError: Pants cannot infer owners for the following imports in the target test/core/foo_test/unit_tests/test_bar.py:tests:

  * pytest (line: 2)

These imports are not in the resolve used by the target (`python-default`), but they were present in other resolves:

  * pytest: 'dev' from reqs:pytest_requirements_dev#pytest

Switching this to

ignore

seems to have no effect since it is still using the pytest specific resolve (we set

install_from_resolve = "dev"

). Why isn't the dependency inference understand this? Also, looking at the example projects it seems that the recommendation is to have runtime and test requirements together in one lock file. Is this true? Should we rather restructure our setup to reflect this?

Yeah, dependency inference usually only works within a single resolve, so explicit imports of pytest will require it being in the same resolve, I think

I need to rephrase my question a bit: We have a special resolve for

pytest

called

dev

. It contains all requirements of

python-default

and all test requirements including

pytest

. When running

pants test ::

everything works as expected. However, during dependency inference checking if

unowned_dependency_behavior = "error"

is set, then it incorrectly tries to infer these dependencies using the

python-default

resolve. To me it looks like

[pytest]
install_from_resolve = "dev"

is ignored during dependency inference. Can you confirm or do we have another misconfiguration elsewhere?

Sorry, I don’t know the answer (and aren’t in a position to find it right now)… but that certainly sounds plausible. Could you file an issue on GitHub so this doesn’t get lost in slack? Thanks

Hello! Was an issue filed on this? Running into the same problem.