Dependency issue when depending on crate [email protected]

[andreareale]

Describe the bug
This is very similar to #8190 which was recently closed. I thought it worth to report it again since it seems persistent, but feel free to close it if you think otherwise.

I was starting to play with the rerun sdk with a minimal toy project and got some dependency-related build failure that looked like an inconsistent dependency between re_types_core and re_arrow2.

error[E0277]: the trait bound `re_arrow2::datatypes::DataType: From<arrow::datatypes::DataType>` is not satisfied
   --> /Users/andrea/.cargo/registry/src/index.crates.io-6f17d22bba15001f/re_types_core-0.21.0/src/datatypes/visible_time_range.rs:229:29
    |
228 |                         return Err(DeserializationError::missing_struct_field(
    |                                    ------------------------------------------ required by a bound introduced by this call
229 |                             Self::arrow_datatype(),
    |                             ^^^^^^^^^^^^^^^^^^^^^^ the trait `From<arrow::datatypes::DataType>` is not implemented for `re_arrow2::datatypes::DataType`, which is required by `arrow::datatypes::DataType: Into<re_arrow2::datatypes::DataType>`
[...l]

To Reproduce
It's very easy to get a minimal repro on my machine. I somehow managed to isolate the issue down to the re_types_core crate, but the issue also occures when using [email protected] as the dependency.

1. $ cargo init foobar && cd foobar
2. $ cargo add [email protected] # the same happens if I depend directly on [email protected]
3. $ cargo build
4. Boom!

More details

• Running: $ cargo update -p re_arrow2 fixes the dependency issue.
  • From a quick, superficial look, it seems that the "fix command" removes an explicit dependency on arrow@54 and only use [email protected]; while the original Cargo.lock seems to pull 54. I am not sure if that is the source of the issue and if so why it is. I am attaching a diff of the Cargo.lock files in case that may be of any help: Cargo.lock.diff.txt.
• Removing Cargo.lock after running cargo update and doign cargo build again, makes the issue appear again.
• I don't get the same behaviour if I use 0.20.3 (both directly for re_types_core or rerun crate)
• I don't get the same behaviour if I build from main

Expected behavior
The build works with no workaround.

Desktop (please complete the following information):

• OS: macOS Sequoia 15.1.1

$ rustup show
Default host: aarch64-apple-darwin
rustup home:  /Users/andrea/.rustup

stable-aarch64-apple-darwin (default)
rustc 1.83.0 (90b35a623 2024-11-26)

Rerun version
0.21.0

[Philosobyte]

I'm running into the exact same issue, but on Windows 11. I do not encounter this issue with 0.20.3.

[astraw]

I made a PR to fix this at rerun-io/re_arrow2#13. You can use it now by adding the following to your Cargo.toml:

[replace]
"re_arrow2:0.18.0" = { git = "https://github.com/rerun-io/re_arrow2", rev = "4049468314caf5e67410539e0a1b72eb4b8d5b22" }

[astraw]

@andreareale indeed your workaround also works as long as one does not then later do a plain cargo update. Out of curiosity, what is the -p option to cargo update? I could not find it documented.

[andreareale]

Out of curiosity, what is the -p option to cargo update? I could not find it documented.

I was under the assumption it was the equicalent of --package, but TIL it has been soft deprecated in favor of a positional argument. In other words, cargo update -p re_arrow2 is equivalent to cargo update re_arrow2.

See source (emphasis on hide(), which explains why it doesn't pop out in docs) and the commit that soft-deprecated it.

[emilk]

Thanks for reporting this! I'll get a new version of re_arrow2 out asap

[emilk]

Fixed! Just run cargo update -p re_arrow2 to fix your build. You should see this:

❯ cargo update -p re_arrow2
    Updating crates.io index
     Locking 1 package to latest compatible version
    Removing arrow-array v54.0.0
    Removing arrow-buffer v54.0.0
    Removing arrow-data v54.0.0
    Removing arrow-schema v54.0.0
    Updating re_arrow2 v0.18.0 -> v0.18.1

Thanks for the report @andreareale and the fix @astraw