fix: treat ignore_root_user_error either ignored or warning by mattem · Pull Request #2739 · bazel-contrib/rules_python

mattem · 2025-04-05T16:04:38Z

Previously #2636 changed the semantics of ignore_root_user_error from "ignore" to "warning". This is now flipped back to ignoring the issue, and will only emit a warning when the attribute is set False.

This does also change the semantics of what #2636 did by flipping the attribute, as now there is no warning, and the user would have to explicitly set it to False (they don't want to ignore the error) to see the warning.

mattem · 2025-04-05T16:05:59Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Perhaps this should be flipped back to False, so the user gets the warning (like they do now with the default), and True is then a true ignore.
Another option would be to make this a tri-state in a non-breaking way, or perhaps add yet another attribute (likely not preferable).

Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

The situation I want to avoid is warning spam
That's excellent to hear, and was the motivation for this diff.
We have quite a number of toolchains registered (arguably too many), and received a lot of warnings (we actually fail builds if too many new log lines are introduced). The change in semantics in #2636 made it hard to remove the warnings, which led to me patching the logger and disabling warnings (now upstreamed as #2737)

rickeylev · 2025-04-05T18:22:54Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

mattem · 2025-04-05T16:04:38Z

Previously #2636 changed the semantics of ignore_root_user_error from "ignore" to "warning". This is now flipped back to ignoring the issue, and will only emit a warning when the attribute is set False.

This does also change the semantics of what #2636 did by flipping the attribute, as now there is no warning, and the user would have to explicitly set it to False (they don't want to ignore the error) to see the warning.

mattem · 2025-04-05T16:05:59Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Perhaps this should be flipped back to False, so the user gets the warning (like they do now with the default), and True is then a true ignore.
Another option would be to make this a tri-state in a non-breaking way, or perhaps add yet another attribute (likely not preferable).

Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

The situation I want to avoid is warning spam
That's excellent to hear, and was the motivation for this diff.
We have quite a number of toolchains registered (arguably too many), and received a lot of warnings (we actually fail builds if too many new log lines are introduced). The change in semantics in #2636 made it hard to remove the warnings, which led to me patching the logger and disabling warnings (now upstreamed as #2737)

rickeylev · 2025-04-05T18:22:54Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

mattem · 2025-04-05T16:04:38Z

Previously #2636 changed the semantics of ignore_root_user_error from "ignore" to "warning". This is now flipped back to ignoring the issue, and will only emit a warning when the attribute is set False.

This does also change the semantics of what #2636 did by flipping the attribute, as now there is no warning, and the user would have to explicitly set it to False (they don't want to ignore the error) to see the warning.

mattem · 2025-04-05T16:05:59Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Perhaps this should be flipped back to False, so the user gets the warning (like they do now with the default), and True is then a true ignore.
Another option would be to make this a tri-state in a non-breaking way, or perhaps add yet another attribute (likely not preferable).

Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

The situation I want to avoid is warning spam
That's excellent to hear, and was the motivation for this diff.
We have quite a number of toolchains registered (arguably too many), and received a lot of warnings (we actually fail builds if too many new log lines are introduced). The change in semantics in #2636 made it hard to remove the warnings, which led to me patching the logger and disabling warnings (now upstreamed as #2737)

rickeylev · 2025-04-05T18:22:54Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

mattem · 2025-04-05T16:04:38Z

Previously #2636 changed the semantics of ignore_root_user_error from "ignore" to "warning". This is now flipped back to ignoring the issue, and will only emit a warning when the attribute is set False.

This does also change the semantics of what #2636 did by flipping the attribute, as now there is no warning, and the user would have to explicitly set it to False (they don't want to ignore the error) to see the warning.

mattem · 2025-04-05T16:05:59Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Perhaps this should be flipped back to False, so the user gets the warning (like they do now with the default), and True is then a true ignore.
Another option would be to make this a tri-state in a non-breaking way, or perhaps add yet another attribute (likely not preferable).

Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

The situation I want to avoid is warning spam
That's excellent to hear, and was the motivation for this diff.
We have quite a number of toolchains registered (arguably too many), and received a lot of warnings (we actually fail builds if too many new log lines are introduced). The change in semantics in #2636 made it hard to remove the warnings, which led to me patching the logger and disabling warnings (now upstreamed as #2737)

rickeylev · 2025-04-05T18:22:54Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

mattem · 2025-04-05T16:04:38Z

Previously #2636 changed the semantics of ignore_root_user_error from "ignore" to "warning". This is now flipped back to ignoring the issue, and will only emit a warning when the attribute is set False.

This does also change the semantics of what #2636 did by flipping the attribute, as now there is no warning, and the user would have to explicitly set it to False (they don't want to ignore the error) to see the warning.

mattem · 2025-04-05T16:05:59Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Perhaps this should be flipped back to False, so the user gets the warning (like they do now with the default), and True is then a true ignore.
Another option would be to make this a tri-state in a non-breaking way, or perhaps add yet another attribute (likely not preferable).

Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

The situation I want to avoid is warning spam
That's excellent to hear, and was the motivation for this diff.
We have quite a number of toolchains registered (arguably too many), and received a lot of warnings (we actually fail builds if too many new log lines are introduced). The change in semantics in #2636 made it hard to remove the warnings, which led to me patching the logger and disabling warnings (now upstreamed as #2737)

rickeylev · 2025-04-05T18:22:54Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

mattem · 2025-04-05T16:04:38Z

Previously #2636 changed the semantics of ignore_root_user_error from "ignore" to "warning". This is now flipped back to ignoring the issue, and will only emit a warning when the attribute is set False.

This does also change the semantics of what #2636 did by flipping the attribute, as now there is no warning, and the user would have to explicitly set it to False (they don't want to ignore the error) to see the warning.

mattem · 2025-04-05T16:05:59Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Perhaps this should be flipped back to False, so the user gets the warning (like they do now with the default), and True is then a true ignore.
Another option would be to make this a tri-state in a non-breaking way, or perhaps add yet another attribute (likely not preferable).

Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

The situation I want to avoid is warning spam
That's excellent to hear, and was the motivation for this diff.
We have quite a number of toolchains registered (arguably too many), and received a lot of warnings (we actually fail builds if too many new log lines are introduced). The change in semantics in #2636 made it hard to remove the warnings, which led to me patching the logger and disabling warnings (now upstreamed as #2737)

rickeylev · 2025-04-05T18:22:54Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

mattem · 2025-04-05T16:04:38Z

Previously #2636 changed the semantics of ignore_root_user_error from "ignore" to "warning". This is now flipped back to ignoring the issue, and will only emit a warning when the attribute is set False.

This does also change the semantics of what #2636 did by flipping the attribute, as now there is no warning, and the user would have to explicitly set it to False (they don't want to ignore the error) to see the warning.

mattem · 2025-04-05T16:05:59Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Perhaps this should be flipped back to False, so the user gets the warning (like they do now with the default), and True is then a true ignore.
Another option would be to make this a tri-state in a non-breaking way, or perhaps add yet another attribute (likely not preferable).

Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

The situation I want to avoid is warning spam
That's excellent to hear, and was the motivation for this diff.
We have quite a number of toolchains registered (arguably too many), and received a lot of warnings (we actually fail builds if too many new log lines are introduced). The change in semantics in #2636 made it hard to remove the warnings, which led to me patching the logger and disabling warnings (now upstreamed as #2737)

rickeylev · 2025-04-05T18:22:54Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

mattem · 2025-04-05T16:04:38Z

Previously #2636 changed the semantics of ignore_root_user_error from "ignore" to "warning". This is now flipped back to ignoring the issue, and will only emit a warning when the attribute is set False.

This does also change the semantics of what #2636 did by flipping the attribute, as now there is no warning, and the user would have to explicitly set it to False (they don't want to ignore the error) to see the warning.

mattem · 2025-04-05T16:05:59Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Perhaps this should be flipped back to False, so the user gets the warning (like they do now with the default), and True is then a true ignore.
Another option would be to make this a tri-state in a non-breaking way, or perhaps add yet another attribute (likely not preferable).

Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

The situation I want to avoid is warning spam
That's excellent to hear, and was the motivation for this diff.
We have quite a number of toolchains registered (arguably too many), and received a lot of warnings (we actually fail builds if too many new log lines are introduced). The change in semantics in #2636 made it hard to remove the warnings, which led to me patching the logger and disabling warnings (now upstreamed as #2737)

rickeylev · 2025-04-05T18:22:54Z

 installation is writable despite being made read only (i.e. it's running with
-root access). If this attribute is set to `False`, Bazel will make it a hard
-error to run with root access instead.
+root access) while this attribute is set `False`, however this messaging can be ignored by setting


Maybe we can have it print a warning if the root module is what configured the toolchain?
The situation I want to avoid is warning spam -- if a downstream user is running as root (for whatever reason), and happens to depend on rules_python (unbeknowst to them, and out of their control), getting warning spam is somewhat annoying.
I do wish we understood the cause here better. I'm mostly sure that the various glob-excludes have fixed this. And there's always the alternative to generate hash-based pyc files at repo-time (when possible) to help avoid the issue further.

fix: treat ignore_root_user_error either ignored or warning
6dcef51

mattem requested review from aignas and rickeylev as code owners April 5, 2025 16:04

mattem commented Apr 5, 2025
View reviewed changes

rickeylev approved these changes Apr 5, 2025
View reviewed changes

rickeylev enabled auto-merge April 5, 2025 18:23

Merge branch 'main' into fix/ignore_root_warning
1b1a211

rickeylev added this pull request to the merge queue Apr 5, 2025

Merged via the queue into bazel-contrib:main with commit 6854dc3Apr 5, 2025

mattem deleted the fix/ignore_root_warning branch April 5, 2025 18:53

mattip mentioned this pull request Aug 19, 2025
update to protbuf-28.2, absl-20240722, grpc-1.67 and patch for windows ray-project/ray#51673
Closed
8 tasks

fix: treat ignore_root_user_error either ignored or warning
6dcef51

mattem requested review from aignas and rickeylev as code owners April 5, 2025 16:04

mattem commented Apr 5, 2025
View reviewed changes

rickeylev approved these changes Apr 5, 2025
View reviewed changes

rickeylev enabled auto-merge April 5, 2025 18:23

Merge branch 'main' into fix/ignore_root_warning
1b1a211

rickeylev added this pull request to the merge queue Apr 5, 2025

Merged via the queue into bazel-contrib:main with commit 6854dc3Apr 5, 2025

mattem deleted the fix/ignore_root_warning branch April 5, 2025 18:53

mattip mentioned this pull request Aug 19, 2025
update to protbuf-28.2, absl-20240722, grpc-1.67 and patch for windows ray-project/ray#51673
Closed
8 tasks

fix: treat ignore_root_user_error either ignored or warning
6dcef51

mattem requested review from aignas and rickeylev as code owners April 5, 2025 16:04

mattem commented Apr 5, 2025
View reviewed changes

rickeylev approved these changes Apr 5, 2025
View reviewed changes

rickeylev enabled auto-merge April 5, 2025 18:23

Merge branch 'main' into fix/ignore_root_warning
1b1a211

rickeylev added this pull request to the merge queue Apr 5, 2025

Merged via the queue into bazel-contrib:main with commit 6854dc3Apr 5, 2025

mattem deleted the fix/ignore_root_warning branch April 5, 2025 18:53

mattip mentioned this pull request Aug 19, 2025
update to protbuf-28.2, absl-20240722, grpc-1.67 and patch for windows ray-project/ray#51673
Closed
8 tasks

fix: treat ignore_root_user_error either ignored or warning
6dcef51

mattem requested review from aignas and rickeylev as code owners April 5, 2025 16:04

mattem commented Apr 5, 2025
View reviewed changes

rickeylev approved these changes Apr 5, 2025
View reviewed changes

rickeylev enabled auto-merge April 5, 2025 18:23

Merge branch 'main' into fix/ignore_root_warning
1b1a211

rickeylev added this pull request to the merge queue Apr 5, 2025

Merged via the queue into bazel-contrib:main with commit 6854dc3Apr 5, 2025

mattem deleted the fix/ignore_root_warning branch April 5, 2025 18:53

mattip mentioned this pull request Aug 19, 2025
update to protbuf-28.2, absl-20240722, grpc-1.67 and patch for windows ray-project/ray#51673
Closed
8 tasks

fix: treat ignore_root_user_error either ignored or warning
6dcef51

mattem requested review from aignas and rickeylev as code owners April 5, 2025 16:04

mattem commented Apr 5, 2025
View reviewed changes

rickeylev approved these changes Apr 5, 2025
View reviewed changes

rickeylev enabled auto-merge April 5, 2025 18:23

Merge branch 'main' into fix/ignore_root_warning
1b1a211

rickeylev added this pull request to the merge queue Apr 5, 2025

Merged via the queue into bazel-contrib:main with commit 6854dc3Apr 5, 2025

mattem deleted the fix/ignore_root_warning branch April 5, 2025 18:53

mattip mentioned this pull request Aug 19, 2025
update to protbuf-28.2, absl-20240722, grpc-1.67 and patch for windows ray-project/ray#51673
Closed
8 tasks

fix: treat ignore_root_user_error either ignored or warning
6dcef51

mattem requested review from aignas and rickeylev as code owners April 5, 2025 16:04

mattem commented Apr 5, 2025
View reviewed changes

rickeylev approved these changes Apr 5, 2025
View reviewed changes

rickeylev enabled auto-merge April 5, 2025 18:23

Merge branch 'main' into fix/ignore_root_warning
1b1a211

rickeylev added this pull request to the merge queue Apr 5, 2025

Merged via the queue into bazel-contrib:main with commit 6854dc3Apr 5, 2025

mattem deleted the fix/ignore_root_warning branch April 5, 2025 18:53

mattip mentioned this pull request Aug 19, 2025
update to protbuf-28.2, absl-20240722, grpc-1.67 and patch for windows ray-project/ray#51673
Closed
8 tasks

fix: treat ignore_root_user_error either ignored or warning
6dcef51

mattem requested review from aignas and rickeylev as code owners April 5, 2025 16:04

mattem commented Apr 5, 2025
View reviewed changes

rickeylev approved these changes Apr 5, 2025
View reviewed changes

rickeylev enabled auto-merge April 5, 2025 18:23

Merge branch 'main' into fix/ignore_root_warning
1b1a211

rickeylev added this pull request to the merge queue Apr 5, 2025

Merged via the queue into bazel-contrib:main with commit 6854dc3Apr 5, 2025

mattem deleted the fix/ignore_root_warning branch April 5, 2025 18:53

mattip mentioned this pull request Aug 19, 2025
update to protbuf-28.2, absl-20240722, grpc-1.67 and patch for windows ray-project/ray#51673
Closed
8 tasks

fix: treat ignore_root_user_error either ignored or warning
6dcef51

mattem requested review from aignas and rickeylev as code owners April 5, 2025 16:04

mattem commented Apr 5, 2025
View reviewed changes

rickeylev approved these changes Apr 5, 2025
View reviewed changes

rickeylev enabled auto-merge April 5, 2025 18:23

Merge branch 'main' into fix/ignore_root_warning
1b1a211

rickeylev added this pull request to the merge queue Apr 5, 2025

Merged via the queue into bazel-contrib:main with commit 6854dc3Apr 5, 2025

mattem deleted the fix/ignore_root_warning branch April 5, 2025 18:53

mattip mentioned this pull request Aug 19, 2025
update to protbuf-28.2, absl-20240722, grpc-1.67 and patch for windows ray-project/ray#51673
Closed
8 tasks

Uh oh!

Uh oh!

Conversation

mattem commented Apr 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

mattem commented Apr 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

mattem commented Apr 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

mattem commented Apr 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects