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.

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...

I just wanted to include this sqlglot PR, so I tried to add sqlglot>=25.30.0 as a dependency to my app. But my app also depends on the latest stable release of ibis, which is 9.5.0. But ibis 9.5.0 has a range of >=23.4,<25.21, implemented by dependabot in #10050. This incompatibility prevents me from uv locking my app.

I hear you on keeping upper bounds when we KNOW that there is an incompatibility. But it looks to me like dependabot was bumping the upper bound to the latest released version. ie it was speculating that all future releases would be incompatible. I suppose that running sqlglot==25.30.0 at the same time as ibis-framework==9.5.0 may be buggy, and ME as the end user wouldn't notice, because I don't have a comprehensive enough test suite, and thus I get incorrect behavior. Only if I ran the entire ibis test suite would I notice the problem. So I guess you could be protecting me from shooting myself in the foot, but I would think it is much more likely that an incompatibility would cause a crash rather than incorrect behavior, and that the benefits of pulling in a needed patch would outweigh the risks.

Is there some other workaround that you know of where I can use sqlglot>=25.30.0 at the same time as ibis-framework==9.5.0? I could also wait for the weekly ibis pre-release to drop on pypi.

I hear you on keeping upper bounds when we KNOW that there is an incompatibility

Yup, same. To quote the article above

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. Anyone can fix a missing cap, but users cannot fix an over restrictive cap causing solver errors.

I'd appreciate it if could also not cap:

• atpublic
• parsy
• python-dateutil
• toolz
• typing-extensions

thanks 🙏