I'm now trying the 2.16's new feature: visibility checks. It seems to be working as expected mostly, but I found a strange behavior with multiple resolves:

> pants dependencies ::
22:25:20.72 [ERROR] 1 Exception encountered:

Engine traceback:
  in `dependencies` goal

DependencyRuleActionDeniedError: src/ai/backend/kernel:reqs#async-timeout has 1 dependency violation:

  * src/ai/backend/kernel/BUILD[!*] -> : DENY
    python_requirements src/ai/backend/kernel:reqs#async-timeout -> _lockfiles //python-kernel.lock:_python-kernel_lockfile

I'm not sure how to "allow" this dependency. Tried

reqs#*

,

:reqs#*

,

/reqs#*

, but didn't work, whereas

src/ai/backend/kernel

directory has its own resolve with its own

python_requirements(name="reqs", ...)

target.

Hi Joongi, thanks for sharing! The visibility rules don’t do transitiveness. There is an implicit dependency (via the “hidden”

_lockfiles

synthetic target) from requirement targets to the generated lockfile. This was done so that if you update the lockfile, your source targets using those requirements will be invalidated if the lockfile changes even if you didn’t change anything in the requirements.txt file directly. (i.e. due to changes in any of the locked transitive dependencies.) Does this explain it properly in your experience as well?

yes, and i realized that both

//reqs#*

and

//python.lock

are already implicitly included via the "default" dependency rule from the root

BUILD

, while

//src/ai/backend/kernel/reqs#*

and

//python-kernel.lock

needs to be explicitly specified. Thanks!

yea, targets in repo root gets a slightly weird treatment wrgt visibility paths..