Hey Pants team, I'm looking to improve the tailoring process for a project by ensuring dependencies are set for targets that are not imported. For example, a case like

api.py

in a module, we want the tests for this module to have this as a dependency

python_tests(dependencies=[app/module_1/api.py])

. I was thinking either a custom plugin (maybe somehow hooks into to tailor) or possibly a macro. Curious if anyone has done something similar or have a suggestion on best approach for this.

Hi! Is it not possible to infer the dependency? An alternative approach is to add a dependency inference plugin

unfortunately no these are not imported in test modules. So we often miss out on these dependees when running tests. Have not consider a dependency inference plugin, is there any examples we can refer to?

unfortunately no these are not imported in test modules.

Imported in what way? Test imports should still work

yes test imports still work but any changes to

api.py

will not run required tests. We want to automate to ensure on changes to

api.py

we run required tests

so there is no line like

import foo.api

, right?

yeah that's correct no direct import in tests

cool. I recommend a dependency inference plugin rather than

tailor

-- when it's possible to infer, we generally encourage that A relevant example is how we infer deps on init.py. It's relevant because it's based purely on file paths, rather than parsing the .py file contents. https://github.com/pantsbuild/pants/blob/c0ba9ffeeb98e9ec17ad4bf69f98470ef113a1d5/src/python/pants/backend/python/dependency_inference/rules.py#L464

awesome that sounds like the right approach. Will this override the default dependency inference or just extend it with our additional logic?

augments 🙂

UnionRule

the bread and butter here for augmenting??

yeah, UnionRule is the key to how all plugin hooks work. With dep inference, we implemented the hook so you can have multiple implementations at the same time Other plugin hooks like

setup-py

require a target only has one implementation, due to ambiguity

okay great thank you for the details. Let me give that approach a try