https://pantsbuild.org/ logo
#development
Title
# development
c

curved-television-6568

07/07/2022, 7:48 PM
Revisiting my visibility PR, there’s a failed check from CI I’m looking at: 🧵
Copy code
pants.backend.visibility.validate.VisibilityViolationError: The following 1 target is not visible to 3rdparty/python#pytest:
  * 3rdparty/python/requirements.txt has visibility: ::
And this is due to the fact that when I request all targets for
Copy code
await MultiGet(Get(Addresses, Specs, specs) for specs in targets_visibility_specs.values()),
I get all addresses for the specs, but it excludes target generators, it would seem..
so it feels like it would make sense, to ignore validating dependencies that are generators, and only consider non-generator targets in the list of dependencies.
in which case, the above error would not fire.
Another question is about if the visibility rules should be applied transitively or not. Consider this scenario:
3rdparty/python#fastapi
-> visibility
src/python/backend/explorer::
Then if I in, say,
src/python/backend/docker/rules.py
have:
Copy code
import fastapi  # ValidationError!
import pants.backend.explorer.graphql.rules  # OK? although we now transitively depend on fastapi!
One way to treat the transitive aspect could be to inherit the visibility of your dependencies.
But I think it may become a rather heavy computational operation to process… another option is to leave it up to the BUILD file author to implement the desired behaviour. For the above example, we could simply add the following to
src/python/pants/backend/explorer/BUILD
Copy code
__defaults__(all=dict(visibility=[f"{build_file_dir()}::"]))
And now, we’ve enforced that only code in the explorer backend may depend on fastapi, and nothing outside of the explorer backend may depend on any part of the explorer backend, effectively locking out access also transitively to the fastapi dependency to the wider pants repo.
5 Views