deps: change rules_antlr fork #4362
Conversation
The fork of rules_antlr that we depend on has disappeared https://github.com/artisoft-io We switch to another fork that contains the same changes that artisoft-io had.
There was a problem hiding this comment.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion
a discussion (no related file):
@matzf should create forks in the scionproto organization for these types of dependencies.
Go dependencies should be pretty safe, because the global go module cache keeps copies even if the repository is deleted.
There was a problem hiding this comment.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion
a discussion (no related file):
@matzf should we create forks in the scionproto organization for these types of dependencies?
There was a problem hiding this comment.
Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @oncilla)
a discussion (no related file):
Previously, oncilla (Dominik Roos) wrote…
@matzf should we create forks in the scionproto organization for these types of dependencies?
These types of dependencies would be bazel build rules that are not part of the github.com/bazelbuild organisation?
- https://github.com/bacek/rules_antlr/
- https://github.com/apple/apple_rules_lint/
- https://github.com/petermylemans/rules_deb_packages/
- https://github.com/rules-proto-grpc/rules_proto_grpc/
Which ones would do you feel we should keep a fork of? My gut feeling is that at least the last one seems fairly safe to rely one.
As an alternative to maintaining a git fork, would it make sense to "vendor" these archives directly into the workspace?
The advantage would be that no help from organisation admins is necessary to add/change dependencies.
These archives seem to be quite small, so putting them directly in the repo seems sane enough (the antlr one is the biggest at 112KB).
There was a problem hiding this comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @matzf)
a discussion (no related file):
Previously, matzf (Matthias Frei) wrote…
These types of dependencies would be bazel build rules that are not part of the github.com/bazelbuild organisation?
- https://github.com/bacek/rules_antlr/
- https://github.com/apple/apple_rules_lint/
- https://github.com/petermylemans/rules_deb_packages/
- https://github.com/rules-proto-grpc/rules_proto_grpc/
Which ones would do you feel we should keep a fork of? My gut feeling is that at least the last one seems fairly safe to rely one.
As an alternative to maintaining a git fork, would it make sense to "vendor" these archives directly into the workspace?
The advantage would be that no help from organisation admins is necessary to add/change dependencies.
These archives seem to be quite small, so putting them directly in the repo seems sane enough (the antlr one is the biggest at 112KB).
Probably antlr and rules deb are the riskiest.
apple and grpc should be safe, given the companies that are behind it.
There was a problem hiding this comment.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @matzf)
a discussion (no related file):
Previously, oncilla (Dominik Roos) wrote…
Probably antlr and rules deb are the riskiest.
apple and grpc should be safe, given the companies that are behind it.
I will merge to fix this in the meantime. We can talk about future strategies afterwards: #4365
There was a problem hiding this comment.
Dismissed @matzf from a discussion.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @matzf)
The fork of rules_antlr that we depend on has disappeared https://github.com/artisoft-io
We switch to another fork that contains the same changes that artisoft-io had.
This change is