@gforsyth I would like to register a complaint:
ibis-framework puts an upper pin on the version of Python it supports which meant the naive pip install path gave me ibis 2.0.0 (because I'm working in a py312 env!) which has incompatibilities with SqlAlchemy 2.0.0b4.
ibis almost got a very spurious bug report, but instead I'm whining at you on social media 😆
@tacaswell apologies! That's always a frustrating experience. We've loosened the upper pin but that's only in dev. The good (better?) news is that our next release is in January and there's a boatload of new features alongside friendlier dependencies.
@gforsyth @tacaswell FWIW while you are loosening pins it looks like you upper pin like... all your dependencies, which is a recipe for disaster in the long run. See, e.g.: https://iscinumpy.gitlab.io/post/bound-version-constraints/
I'm guessing this is a side effect of using poetry: https://iscinumpy.dev/post/poetry-versions/
This is also a good use-case for post-facto dependency adjustment on a packaging system.
When I learned that conda-forge does this I was first a bit horrified (mostly because I burned a day with things being broken due to locally extracted, unpatched, and hence wrong dependency graph) but have come around to this being required (and this is on top of the fact that conda (/fedora/debian/brew/...) already is inherently post-tag dependency pinning.
@pganssle @gforsyth @tacaswell on a related note, @tomasino posted an idea about contract-based dependency which sounds like a great idea
@xarvos @gforsyth @tacaswell @tomasino I don't think that's going to solve any of the problems around semver-based pinning.
@pganssle @gforsyth
Indeed, trying to install the dev version is trying to down-grade my pandas from their main branch to a released version 😞
sed s/,</,<9999./g
fixed that problem!