Revisiting my visibility PR, there’s a failed chec...
# developmentc
curved-television-6568
07/07/2022, 7:48 PMRevisiting my visibility PR, there’s a failed check from CI I’m looking at: 🧵
curved-television-6568
07/07/2022, 7:48 PM Copy code
pants.backend.visibility.validate.VisibilityViolationError: The following 1 target is not visible to 3rdparty/python#pytest:
* 3rdparty/python/requirements.txt has visibility: ::curved-television-6568
07/07/2022, 7:50 PMAnd 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()),curved-television-6568
07/07/2022, 7:50 PMso 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.
curved-television-6568
07/07/2022, 7:51 PMin which case, the above error would not fire.
curved-television-6568
07/07/2022, 8:27 PMAnother question is about if the visibility rules should be applied transitively or not.
Consider this scenario:
3rdparty/python#fastapisrc/python/backend/explorer::src/python/backend/docker/rules.py Copy code
import fastapi # ValidationError!
import pants.backend.explorer.graphql.rules # OK? although we now transitively depend on fastapi!curved-television-6568
07/07/2022, 8:29 PMOne way to treat the transitive aspect could be to inherit the visibility of your dependencies.
curved-television-6568
07/07/2022, 8:32 PMBut 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()}::"]))5 Views