Please consider not setting upper-bounds on dependencies

[MarcoGorelli]

Hey, well done with SQLFrame, and thanks for the quick fixes, I'm taking a look at how to support / build on it in Narwhals

May I suggest you consider not setting upper bounds on dependencies?
This can cause issues in CI. For example here an upper bound on pyarrow in ibis was blocking upgrading to Python 3.13

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.

[eakmanrq]

Hey, well done with SQLFrame, and thanks for the quick fixes, I'm taking a look at how to support / build on it in Narwhals

Thanks and that is really exciting! I appreciate you not only looking to integrate it into Narwhals but also taking the time to open these issues!

I do agree with the library argument that libraries are easier to integrate if they have minimal opinions in general on their dependencies.

The tradeoff though for those using SQLFrame as as standalone application, then not having the caps on versions can result in them installing SQLFrame and having a broken result because SQLFrame claims that it is compatible with all version of some library when really it is not.

Therefore I'm a bit mixed on this. Here are the ways I try to address this:

• Minimize required dependencies (ignoring the connector for the engine, this is 3 currently)
• Depend on the highest level version for a package that makes sense for the release cycle of that package
  • Ex: I depend on minor for SQLGlot since any changes to SQLGlot can be significant to SQLFrame. I depend on major for typing_extensions since this doesn't really matter.
• Keep up with latest releases with dependabot and try to get compatibility with breaking changes as quickly as possible

I know that this combination doesn't resolve the issue introduced by having limits, but my hope is that it minimizes the impact to where I can sit in the middle-ground between library and end-application.

I also plan on taking a pass soon to loosen some of the current versions in SQLFrame since in some cases it is currently too strict.