Fix build - update arrow to 54.2.1

[legendre6891]

Arrow 54.2.0 is broken and a hotfix 54.2.1 was issued.

Without bumping the arrow version, this package does not build by default.

$ cargo new --lib tmp
$ cd tmp
$ cargo add pyo3-arrow
$ cargo build

-- snip --
error[E0034]: multiple applicable items in scope
92  |         DatePart::Quarter => |d| d.quarter() as i32,
    |                                    ^^^^^^^ multiple `quarter` found
    |
note: candidate #1 is defined in the trait `ChronoDateExt`
-- snip --

[kylebarron]

Can't you pin to 54.2.1 in your own code? pyo3-arrow is set to 54 for the arrow dependency, which means that it's semver compatible with 54.2.1. I don't want to bump to 54.2.1 because that means this library would no longer be compatible for anyone still using 54.0 or 54.1.

[legendre6891]

You’re right, I could indeed add an explicit requirement in my own project.

The point of this PR is to highlight that a library whose only specified dependency is pyo3-arrow cannot be built. I think this is worth fixing.

That said, I hear you on the compatibility considerations for users of arrow 54.0/54.1. Perhaps the onus is on arrow to pull 54.2.

[kylebarron]

You’re right, I could indeed add an explicit requirement in my own project.

I'm not sure how to use pyo3-arrow without a dependency on arrow in your own project... pyo3-arrow only gives you the Python I/O, but you still need arrow to do anything with the data in Rust.

The point of this PR is to highlight that a library whose only specified dependency is pyo3-arrow cannot be built. I think this is worth fixing.

Interesting... this seems to be something specific with the cargo resolver. When I don't pin 54.2.1 specifically, it does downgrade arrow to 54.2.0:

Perhaps chrono has higher priority for some reason?

Ideally I would change this to:

arrow = "54,!=54.2.0"

So that any 54.* version is allowed except 54.2.0, but Cargo does not allow this.

So I don't think there's anything we can realistically do here if we want to still support users on 54.0 and 54.1.

[legendre6891]

Agreed -- probably nothing we could do for now -- it would be best if the hypothetical arrow = "54,!=54.2.0" were supported.