Conversation
Signed-off-by: dentiny <dentinyhao@gmail.com>
| # OpenCensus depends on Abseil so we have to explicitly pull it in. | ||
| # This is how diamond dependencies are prevented. | ||
| # | ||
| # TODO(owner): Upgrade abseil to latest version after protobuf updated, which requires to upgrade `rules_cc` first. |
There was a problem hiding this comment.
Error when I was trying to further bump up version:
external/com_google_protobuf/src/google/protobuf/arena.cc:472:49: error: 'Layout' in namespace 'absl::lts_20240116::container_internal' does not name a template type
472 | using layout_type = absl::container_internal::Layout<
| ^~~~~~
external/com_google_protobuf/src/google/protobuf/arena.cc:494:20: error: 'layout_type' does not name a type
494 | constexpr static layout_type Layout(size_t n) {
| ^~~~~~~~~~~
which means our protobuf and abseil are too old so google side directly removes the interface :(
|
what feature do you want from this abseil version? NonNull? |
|
Just curious on what a |
Yes, it's released in newer version.
Old google coding style suggests using pointer instead of referencer for in-out params, I do see quite a few patterns in our codebase. For your question, I think But overall, it's just a detailed example, which makes realized we're on a pretty stale abseil version; |
|
hmm I am not convinced that For this specific PR we can accept it because at least we can know it compiles by CI. Later if you want to upgrade something we can first have a talk. |
As I mentioned in the PR description, I definitely want to upgrade the core libraries that we use to the latest version, but due the stale dependencies that we have (protobuf and rules cc), this is the latest workable release I could find. |
Well I don't agree with it TBH; I think dependencies should be checked and upgraded periodically. I get stuck into such situation in my previous company --- GCS SDK introduces key security features that we have to use, but our libraries is 5 major versions behind, which takes three engineers a full month to upgrade all necessary dependencies, I, as an eng which take part in the upgrade process, definitely don't want to have the same experience again :( |
Let's forget about the library, it's just a trigger which prompts me we're on a stale version. |
I think there're two things here:
|
|
volunteer mode also sounds ok to me. We need to take a more closed look at each release's performance impacts though. |
|
There're some auto-upgrade bots: https://github.com/apps/renovate |
Signed-off-by: dentiny <dentinyhao@gmail.com>
… using modern absl (#48722) In [src/ray/object_manager/common.cc](https://github.com/ray-project/ray/blob/e393a716d8742a987a36df555defb2ca90bb94d4/src/ray/object_manager/common.cc) we extensively use `absl::StrCat` without explicitely importing the associated header `absl/strings/str_cat.h`. It worked fine previously, as `absl/strings/str_format.h` transitively included that via absl internal headers. However, somewhere in 2023-2024, absl has been cleaned up from unintentional transitive includes, breaking `ray` builds against modern absl. This PR fixes that. ## Effect on backward/forward compatability None. Builds against older absl versions will continue to work as before, as `absl::StrCat` was always declared in `str_cat.h` and including that was always the intended way to import this symbol. ## Related issues/PRs: + #48667 --------- Signed-off-by: gorloffslava <31761951+gorloffslava@users.noreply.github.com> Signed-off-by: Slava Gorlov <31761951+gorloffslava@users.noreply.github.com>
… using modern absl (ray-project#48722) In [src/ray/object_manager/common.cc](https://github.com/ray-project/ray/blob/e393a716d8742a987a36df555defb2ca90bb94d4/src/ray/object_manager/common.cc) we extensively use `absl::StrCat` without explicitely importing the associated header `absl/strings/str_cat.h`. It worked fine previously, as `absl/strings/str_format.h` transitively included that via absl internal headers. However, somewhere in 2023-2024, absl has been cleaned up from unintentional transitive includes, breaking `ray` builds against modern absl. This PR fixes that. ## Effect on backward/forward compatability None. Builds against older absl versions will continue to work as before, as `absl::StrCat` was always declared in `str_cat.h` and including that was always the intended way to import this symbol. ## Related issues/PRs: + ray-project#48667 --------- Signed-off-by: gorloffslava <31761951+gorloffslava@users.noreply.github.com> Signed-off-by: Slava Gorlov <31761951+gorloffslava@users.noreply.github.com> Signed-off-by: Connor Sanders <connor@elastiflow.com>
… using modern absl (ray-project#48722) In [src/ray/object_manager/common.cc](https://github.com/ray-project/ray/blob/e393a716d8742a987a36df555defb2ca90bb94d4/src/ray/object_manager/common.cc) we extensively use `absl::StrCat` without explicitely importing the associated header `absl/strings/str_cat.h`. It worked fine previously, as `absl/strings/str_format.h` transitively included that via absl internal headers. However, somewhere in 2023-2024, absl has been cleaned up from unintentional transitive includes, breaking `ray` builds against modern absl. This PR fixes that. ## Effect on backward/forward compatability None. Builds against older absl versions will continue to work as before, as `absl::StrCat` was always declared in `str_cat.h` and including that was always the intended way to import this symbol. ## Related issues/PRs: + ray-project#48667 --------- Signed-off-by: gorloffslava <31761951+gorloffslava@users.noreply.github.com> Signed-off-by: Slava Gorlov <31761951+gorloffslava@users.noreply.github.com> Signed-off-by: ujjawal-khare <ujjawal.khare@dream11.com>
I want to leverage new abseil utils, for example
absl::NotNull, but it's not available in our current version.The final goal is to keep all our third party dependencies to their latest version, but unfortunately,