3

I am developing a python package called RivGraph. I've recently run into an issue related to geopandas' decision to overhaul CRS representation, as described here and here. The short of it is that in geopandas versions <0.7, crs's were stored as dictionaries of proj4 strings, e.g. {'init':'epsg:4326'}. In geopandas 0.7 and moving forward, crs's are stored as pyproj objects, which are richer and more robust. Ok, great.

I share RivGraph as a conda-installable, and direct people to install it using conda to ensure all the dependencies are worked out. What I've discovered is that, depending on the user's platform, sometimes geopandas <0.7 is installed, and sometimes geopandas 0.7 is installed. So that leads me to ask this question:

What is the best way to make my package compatible with both of these versions of geopandas? I guess I realize that I can check the geopandas version in my package, and write if statements that use one syntax vs. the other, but this seems tedious and ugly. I can't quite figure out if there is a single syntax that is compatible across both versions of geopandas when it comes to crs management.

Improve this question
2
  • Not an answer since I'm suggesting you don't try to support both when you're developing a new package, but you could specify geopandas >= 0.7 in your package requirements. Conda environments are disposable and it's easy to just conda create a new environment with an up to date geopandas if users get conflicts trying to install your package in an existing environment.
    – user2856
    Commented Jun 2, 2020 at 4:50
  • I generally agree, but the issue is that I developed most of my package before 0.7 existed, so it already has full support for <0.7. Not sure if it makes sense to strip that out.
    – Jon
    Commented Jun 2, 2020 at 14:50

1 Answer 1

Reset to default
2

One option is to pin your package to >=0.7. Otherwise, here is a guide for you: https://pyproj4.github.io/pyproj/stable/crs_compatibility.html#geopandas

Improve this answer
3
  • Reposting a comment from above: I generally agree, but the issue is that I developed most of my package before 0.7 existed, so it already has full support for <0.7. Not sure if it makes sense to strip that out and replace with 0.7 syntax. That's why I was hoping for a single solution for both versions.
    – Jon
    Commented Jun 2, 2020 at 14:51
  • Makes sense. Did the link above answer your question?
    – snowman2
    Commented Jun 2, 2020 at 15:15
  • I guess so. It looks like the version check is unavoidable, so I guess that's the answer. The other thing is that pyproj < v2 is sometimes installed as well, which has a different syntax compared with >v2 as well. It looks like the best thing to do is to pin to >=0.7 to avoid both issues.
    – Jon
    Commented Jun 2, 2020 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.