Hi all, I've got a bunch of test files that I need to run under multiple

extra_env_vars

conditions. So I'm using parametrize (which is straightforward and makes sense). However, this seems to cause some target/dependency issues: I have a test file

test_file_a.py

which also contains a utility function.

test_file_b.py

wants to use this utility function, so it imports

test_file_a.py

Now, because of parametrize, I have warnings like this:

11:17:39.94 [WARN] The target backend/test/integration/test_file_b.py:tests@extra_env_vars=config2 imports `test.integration.test_file_a.utility_function`, but Pants cannot safely infer a dependency because more than one target owns this module, so it is ambiguous which to use: ['backend/test/integration/test_file_a.py:tests@extra_env_vars=config1', 'backend/test/integration/test_file_a.py:tests@extra_env_vars=config2'].

Please explicitly include the dependency you want in the `dependencies` field of backend/test/integration/test_file_b.py:tests@extra_env_vars=config1, or ignore the ones you do not want by prefixing with `!` or `!!` so that one or no targets are left.

Alternatively, you can remove the ambiguity by deleting/changing some of the targets so that only 1 target owns this module. Refer to <https://www.pantsbuild.org/2.21/docs/using-pants/troubleshooting-common-issues#import-errors-and-missing-dependencies>.

Is there some way I can get pants to understand that a particular parametrized target should use the equivalently parametrized target as its dependency? Long term, I think the ideal thing is to get the utility functions out of the test files and into a common

python_source()

that doesn't get parametrized, but in the meantime, is there some way to get pants to understand?

I'm struggling with exactly this also 😞

Logically, it seems that the test files ought to be "leaf nodes" in the dependency graph, and not be imported by anything else. That would fix this. But developers (like me) don't always see it that way and the quick fix is to just import something instead of bothering to extract it out and organize a utility file

The fact that source/test files are "within" a resolve at all is sometimes counter-productive