-
Notifications
You must be signed in to change notification settings - Fork 478
Remove usage of grep_includes #2072
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This change relies on changes that landed in Bazel 6.3, and as such our min version (6.0) builds are failing. We have the option of: @UebelAndre @illicitonion , do you have a stance on updating the min supported version to 6.3? @kotlaja in case the maintainers would like to keep compatibility with 6.0, is there some API exposed that we could use to conditionally select on API versions (e.g a |
Consider using https://github.com/bazel-contrib/bazel_features to do the conditional selection ;) You can submit a feature condition here: https://github.com/bazel-contrib/bazel_features/blob/8fbef9fce356d87f8221a217e1e1b6c9dae69604/features.bzl#L10 |
I'm ok with bumping to 6.3.0. In #415 we discussed basically wanting all of:
I guess the spirit of following that policy is that we'd wait 3 months until bumping from 6.2 to 6.3, but in practice I haven't seen any regressions in minor releases, so don't think there's likely to be a strong need for someone to stay on 6.2 when 6.3 is out. |
It's also worth pointing out that for end users, migrating from 6.2 to 6.3 should be effortless since the newer version should be fully backwards compatible, if not then it's a bug we should fix. |
@scentini No, there isn't. And there shouldn't be an issue with compatibility since grep_includes are fully internal (externally there is a binary which should never be executed since grep_includes are not supported outside Google). And for internal case I'll come back to you on the internal chat.
@illicitonion Perfect, thank you! When can we expect this to happen? Just to know since this change is blocking me to continue with other changes. |
I'd like to hear @UebelAndre's opinion on updating min Bazel to 6.3 too before proceeding with this change. If they prefer to keep compatibility with 6.0 we will ask for this PR to be modified so that |
A future Bazel version will contain a breaking API change. #2072 is preparing the `rules_rust` codebase for it, however it relies on Bazel API changes present in `6.3.0` and not `6.0.0`. As per discussion there #2072 (comment), looks like maintainers are fine with bumping the minimum Bazel version to `6.3.0`.
I think we would need to show our min target version continues to work in some way. If there are flags we can make and/or pass to achieve this then I think most changes people wanna make are fine. 😄 |
Thanks @scentini for bumping the min Bazel version supported by rules_rust! I really appreciate it! :) Related to this PR, the |
@UebelAndre we were talking about updating the min version altogether so that we don't have to maintain branches of the likes of |
A future Bazel version will contain a breaking API change. bazelbuild#2072 is preparing the `rules_rust` codebase for it, however it relies on Bazel API changes present in `6.3.0` and not `6.0.0`. As per discussion there bazelbuild#2072 (comment), looks like maintainers are fine with bumping the minimum Bazel version to `6.3.0`.
No description provided.