Kyle Barron

@nmandery I'll need some feedback in terms of how open you are to breaking changes. In particular, you have separate APIs for `h3ronpy.polars`, `h3ronpy.pandas`, and `h3ronpy.arrow`. This is really complex...

> The only thing I would like to keep is the polars extensions to the `Expr` and `Series` namespaces. 👍 I definitely agree there

CI failed on commit [`5132e01` (#64)](https://github.com/nmandery/h3ronpy/pull/64/commits/5132e017b4d9678a7a00c4e7ed77cfa2767fc8ac) with: ``` error[E0275]: overflow evaluating the requirement `::GeometryCollection | ^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... 109 | / impl_iterator!( 110 | | GeometryCollectionIterator, 111 | | GeometryCollectionTrait,...

@nmandery is it ok with you if the _raster_ -specific code still has a pyarrow dependency for now? It would be nice to come back to that in a follow...

How do you want to handle these polars and pandas tests? Should we keep them and update them to use the current arrow-based APIs?

At least locally the tests are passing now. Hopefully CI will be green as well

Actually @zacharydez is working on a project that I think is using h3ronpy in AWS Lambda, and this would benefit them because pyarrow is too big to put in Lambda...