Enforce inter-package visibility constraints via protoxform generated BUILD #8491
Assignees
Labels
Comments
htuch
added
no stalebot
htuch
added a commit
to htuch/envoy
that referenced
this issue
Oct 4, 2019
As part of envoyproxy#8082, we want to be able to (1) automatically generate BUILD files and (2) treat packages as atomic from a "upgrade / do not upgrade" decision perspective. This is simplified by having our BUILD targets at package granularity, since this is what the protoxform plugin operates on. This PR broadens the package-level treatment that was already introduced for Go in envoyproxy#8003 to Python and C++. This simplifies BUILD files significantly and opens the way to automated generation. There is some technical debt introduced, since all visibility controls have been removed. This is slated for reintroduction in envoyproxy#8491. As a bonus (useful for BUILD file generation), also removed the inconsistency in BUILD package target naming for packages in envoy.api.* and envoy.type.*. E.g. //envoy/api/v2:v2 is now //envoy/api/v2:pkg. Risk level: Low (but this will break internal builds and require BUILD fixups to consuming projects). Testing: bazel test //test/... @envoy_api//... Signed-off-by: Harvey Tuch <[email protected]>
htuch
added a commit
that referenced
this issue
Oct 6, 2019
As part of #8082, we want to be able to (1) automatically generate BUILD files and (2) treat packages as atomic from a "upgrade / do not upgrade" decision perspective. This is simplified by having our BUILD targets at package granularity, since this is what the protoxform plugin operates on. This PR broadens the package-level treatment that was already introduced for Go in #8003 to Python and C++. This simplifies BUILD files significantly and opens the way to automated generation. There is some technical debt introduced, since all visibility controls have been removed. This is slated for reintroduction in #8491. As a bonus (useful for BUILD file generation), also removed the inconsistency in BUILD package target naming for packages in envoy.api.* and envoy.type.*. E.g. //envoy/api/v2:v2 is now //envoy/api/v2:pkg. Risk level: Low (but this will break internal builds and require BUILD fixups to consuming projects). Testing: bazel test //test/... @envoy_api//... Signed-off-by: Harvey Tuch <[email protected]>
mattklein123
pushed a commit
to envoyproxy/data-plane-api
that referenced
this issue
Oct 6, 2019
As part of #8082, we want to be able to (1) automatically generate BUILD files and (2) treat packages as atomic from a "upgrade / do not upgrade" decision perspective. This is simplified by having our BUILD targets at package granularity, since this is what the protoxform plugin operates on. This PR broadens the package-level treatment that was already introduced for Go in #8003 to Python and C++. This simplifies BUILD files significantly and opens the way to automated generation. There is some technical debt introduced, since all visibility controls have been removed. This is slated for reintroduction in envoyproxy/envoy#8491. As a bonus (useful for BUILD file generation), also removed the inconsistency in BUILD package target naming for packages in envoy.api.* and envoy.type.*. E.g. //envoy/api/v2:v2 is now //envoy/api/v2:pkg. Risk level: Low (but this will break internal builds and require BUILD fixups to consuming projects). Testing: bazel test //test/... @envoy_api//... Signed-off-by: Harvey Tuch <[email protected]> Mirrored from https://github.com/envoyproxy/envoy @ 4e858f17fe08224c9c089240908ccd0c518e01a7
nandu-vinodan
pushed a commit
to nandu-vinodan/envoy
that referenced
this issue
Oct 17, 2019
) As part of envoyproxy#8082, we want to be able to (1) automatically generate BUILD files and (2) treat packages as atomic from a "upgrade / do not upgrade" decision perspective. This is simplified by having our BUILD targets at package granularity, since this is what the protoxform plugin operates on. This PR broadens the package-level treatment that was already introduced for Go in envoyproxy#8003 to Python and C++. This simplifies BUILD files significantly and opens the way to automated generation. There is some technical debt introduced, since all visibility controls have been removed. This is slated for reintroduction in envoyproxy#8491. As a bonus (useful for BUILD file generation), also removed the inconsistency in BUILD package target naming for packages in envoy.api.* and envoy.type.*. E.g. //envoy/api/v2:v2 is now //envoy/api/v2:pkg. Risk level: Low (but this will break internal builds and require BUILD fixups to consuming projects). Testing: bazel test //test/... @envoy_api//... Signed-off-by: Harvey Tuch <[email protected]>
|
I think the v3 API structure has largely obsoleted the need for this. We have clear inter-package relationships and given the coarse grained nature of dependencies now operating at package level, Bazel cycles appear the moment that these relationships are violated. Will close this out as a result. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the v3 API, we will have generated BUILD files. As a step towards this, we will remove the existing visibility constraints and reintroduce them later via
protoxformgeneration.Since these constraints are only a convenience for @envoyproxy/api-shepherds to ensure sane structure, will postpone the work here until after 1.12.0 ships.
The text was updated successfully, but these errors were encountered: