feat: please consider not setting upper bounds on dependencies

[MarcoGorelli]

Is your feature request related to a problem?

Ibis currently sets upper bounds on dependencies. E.g. the latest release pins pyarrow<18

What is the motivation behind your request?

This causes issues in CI. For example here it was blocking upgrading to Python 3.13

Describe the solution you'd like

I'd suggest not setting upper bounds on dependencies, as suggested here https://iscinumpy.dev/post/bound-version-constraints/

Capping dependencies has long term negative effects, especially for libraries, and should never be taken lightly. A library is not installed in isolation; it has to live with other libraries in a shared environment. Only add a cap if a dependency is known to be incompatible or there is a high (>75%) chance of it being incompatible in its next release. Do not cap by default - capping dependencies makes your software incompatible with other libraries that also have strict lower limits on dependencies, and limits future fixes.

What version of ibis are you running?

9.5.0

What backend(s) are you using, if any?

Polars

Code of Conduct

• I agree to follow this project's Code of Conduct

[cpcloud]

We can probably do this for pyarrow. IIRC pyarrow releases don't often break Ibis, we're not using that much of its API, and the parts we are using have been around for years.

Doing this for every dependency is not something we should do, given that some of them regularly break Ibis (e.g., sqlglot) and require us to write compatibility code to work around the breakage.

[acuitymd-filip]

That would be amazing to at least lift this for pyarrow - we want to update to pyarrow 18 to benefit from the new string_view stuff in that release, but currently blocked by ibis 9.5 requiring pyarrow<18...