Support for geopandas>=1.0

[scottyhq]

Is your feature request related to a problem? Please describe.

snowexsql/requirements.txt

Line 3 in 830fa76

geopandas>=0.7,<1.0

Describe the solution you'd like

I know it is an age old debate, but depending on how geopandas is used in this library, it seems reasonable to either drop the upper version limit or change to geopandas>=1.0,<2 for long term stability.

Additional context

https://github.com/geopandas/geopandas/releases/tag/v1.0.0

Trying to make snowexsql with other packages on Cryocloud JupyterHub (CryoInTheCloud/hub-image#121)

[micah-prime]

Is your feature request related to a problem? Please describe.

snowexsql/requirements.txt

Line 3 in 830fa76

geopandas>=0.7,<1.0

Describe the solution you'd like

I know it is an age old debate, but depending on how geopandas is used in this library, it seems reasonable to either drop the upper version limit or change to geopandas>=1.0,<2 for long term stability.

Additional context

https://github.com/geopandas/geopandas/releases/tag/v1.0.0

Trying to make snowexsql with other packages on Cryocloud JupyterHub (CryoInTheCloud/hub-image#121)

Hey Scott! My general approach for downstream compatibility is to pin below major versions (<1.0 in this case). Moving to <2.0 this early seems risky since geopandas 1.0 has only been out for a month and has a number of breaking changes. I like to give a package a good amount of time to work out bugs so that there are not unintended consequences to the shift.

What packages are requiring geopandas>=1.0 in this case?

[scottyhq]

What packages are requiring geopandas>=1.0 in this case?

I should've clarified, nothing is requiring geopandas>=1 in this case, it's just that I want to use it :) As a user, I see v1 and think "that's what I should be using because it's stable"... but then again, Python counting starts at zero :). The latest release also tends to be the default documented version that users interact with (e.g. https://geopandas.org/en/stable) so it's easy to get confused if there are syntax changes.

I definitely understand the arguments though around risk for things breaking. One strategy that I find useful is running a CI workflow against unpinned dependencies, that way you're aware of changes that might be necessary to support major releases of dependencies. I'd be happy to submit a PR for that if you think it'd be useful as a way to try this out?

[micah-prime]

What packages are requiring geopandas>=1.0 in this case?

I should've clarified, nothing is requiring geopandas>=1 in this case, it's just that I want to use it :) As a user, I see v1 and think "that's what I should be using because it's stable"... but then again, Python counting starts at zero :). The latest release also tends to be the default documented version that users interact with (e.g. https://geopandas.org/en/stable) so it's easy to get confused if there are syntax changes.

I definitely understand the arguments though around risk for things breaking. One strategy that I find useful is running a CI workflow against unpinned dependencies, that way you're aware of changes that might be necessary to support major releases of dependencies. I'd be happy to submit a PR for that if you think it'd be useful as a way to try this out?

Yeah it's hard to know with semantic versioning these days 😆

We'll give it some testing to see if anything surprising occurs. This close to the hackweek we'll proceed with a lot of caution. One concern is that the scientific community is not always on the up-and-up with python versions, and this would required dropping support for Python 3.8 in snowexsql.

We'll let you know how the testing goes!

[micah-prime]

This is addressed in version 0.5.0!