@ljwolf @martinfleis, I might be wrong, but it seems the tests fail on importing pygeos in esda. Is there a recommended workaround?

Tests fail due to the new pygeos usage in esda. Otherwise, everything looks good!

I did not add pygeos to the dependencies over in esda. I can move that to a function-level import, or make it a dependency of esda. I'm leaning towards doing a post-release with the pygeos stuff moved to function-level imports.

@ljwolf @martinfleis, I might be wrong, but it seems the tests fail on importing pygeos in esda. Is there a recommended workaround?

Yeah, this needs to be addressed in esda. I'll have a post release for esda made today that pushes the pygeos import into a function-level import, and then these should be OK. I do not think that esda will adopt a new dependency on this short notice!

@slumnitz Just add pygeos to the CI environments. It is now a hard dependency for esda but that doesn't include it in requirements.txt or its conda-forge feedstock.

edit: seeing @ljwolf's comment I may be wrong.

I've drafted a PR (pysal/esda#188) to address this, and started a consultation on the gitter about making pygeos a dependency at the library level (i.e. a requirement for libpysal).

I am for it, but I just don't want to break folks' environments & intended distributions.

@ljwolf I am happy with either. What are the downsides of making it a library level dependency for esda (especially since it would already be installed through libpysal)?

@martinfleis I am hesitant to add the pygeos dependency hard coded, as most of splot relies on esda and it should be made clear somewhere that it needs an installation.

There's no specific downside to adding it directly to esda, but given its role as a computational geometry infrastructure package, I think pygeos makes the most sense conceptually at the lowest level, especially as we've started to adopt it across packages. That's what we'd discussed as the rule for making things dependencies at the libpysal level: is it related to the core functionality of libpysal (computational geometry & topology), and is it being used across more than libpysal alone.

That said, I think that's a decision for the next 6-month cycle, hence this change in esda, which should land today.

@ljwolf ok thank you, sounds great! Let me know if you need help on the PR!

Codecov Report

Merging #136 (57577fa) into main (2af777e) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #136   +/-   ##
=======================================
  Coverage   85.94%   85.94%           
=======================================
  Files          18       18           
  Lines        1217     1217           
=======================================
  Hits         1046     1046           
  Misses        171      171           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2af777e...57577fa. Read the comment docs.

Great, I've re-run the tests & made a point release for esda. Everything's green here, so this should be good to go!