Should we upgrade to Shapely 2.0 in new riverscapes-tools release?

[jtgilbert]

I'm looking into some calculation of metrics, and there's some useful functionality shapely introduced in v 2.0. There were some significant changes from v 1 to 2 which deprecated some functionality that we'd have to go through and update in our model code, but I think we do it now before Shapely v1 is totally abandoned.
Thoughts @MattReimer @philipbaileynar @KellyMWhitehead @joewheaton

[philipbaileynar]

This is above my pay grade. @MattReimer ?

[MattReimer]

We cannot do this lightly or assume that our tools will work after this upgrade. We did an upgrade to GDAL a while back and I missed that in the new version sometimes the lat and lng are switched so.... yeah. let's not assume anything here

Some questions that need answering:

1. What does the new version depend on? If memory serves, shapely depended on proj4 which is a pretty gnarly compile.
2. Do we have to upgrade anything else?
3. Are there any parts of shapely we use poorly or any exceptions to it we made that will break when we upgrade

I think there is a pretty easy branch experiment to do here. Let's upgrade it on a branch and test the living heck out of it. We need to find every import shapely statement (70+ on quick survey) in all of or code and make sure that we're both hitting and testing it.

Luckily we have unit tests riverscapes-tools/lib/commons/test. I have no idea the last time they were run or if any of them still work but we can use that as a base to start testing again.

Oh also we should realize that this will need updating everywhere we run this code so:

1. Cybercastor
2. All our local environments
3. etc.....?

Obviously this ties nicely into my remote environment experiments right now so watch this space.

[KellyMWhitehead]

https://shapely.readthedocs.io/en/stable/migration.html#migration

I think the biggest impacts here are immutable geometires and iterating through multipart geometries.

[jtgilbert]

Yeah, my impression would be that the main thing we'll need to deal with is multipart iteration.

[MattReimer]

immutable geometries might bite us if we've been sloppy and are editing objects in place but these are antipatterns we should really weed out anyway. Hopefully the errors for this are obvious and we can move through them easily.

For multipart iterations my hope is that we come up with a pattern we can copy and paste to use everywhere consistently. Sounds kind of perfect task for Copilot if you ask me...