Reonsider dependencies

[rafaqz]

• CoordinateTransformations should be easy to put in an extension? (it pulls in StaticArrays)
• GeometryBasics is pulling in Earcut_jll and StaticArrays - do we actually need it for anything?

I just noticed adding GO to another package added all of these, it would be nice not to make that consideration a factor.

[asinghvi17]

We may not need staticarrays, true, but mesh / triangulation support probably needs GeometryBasics. Especially spherical triangulation.

I'm going to try and reduce StaticArrays load times as well which should help a bit.

I currently use the CoordinateTransformations interface for spherical coordinates but we could remove that in theory.

[rafaqz]

Can we insulate everything else from meshes using an extension? Most basic work doesn't need it

Having a dependency on Earcut_jll is unnecessary for most of the package

[asinghvi17]

True...we can't really insulate meshing from needing an extension but we might be able to remove GeometryBasics at least. I would still want to keep StaticArrays, at least for now. For triangulation we can always return the DelaunayTriangulation.jl object or maybe some tuple of points and faces.

[asinghvi17]

Out of curiosity what prompted this?

[rafaqz]

Seeing the dependencies balloon when I added it to ConScape.jl just for polygon distance calculations.

I would prefer not to have any enforced binary deps, and I'm sure it will make other question adding it in similar contexts. In comparison Rasters is pretty light

[asinghvi17]

Yeah this will also speed up loading GeometryOps by at least a third, probably more like a half.

Not that the load time was that bad anyway (0.3s on my machine, compared to 2.7s for Makie) but still...

The only thing I want to mention here is that we probably shouldn't shy away from including dependencies if it makes life significantly easier (e.g. DelaunayTriangulation, StaticArrays)

[rafaqz]

I shy away!

Mostly those binary deps. But as well as load time dependencies also increase compile time of every environment GO is used in.

(I guess I'm hoping GO can be lower in the stack, with many packages depending on it rather than just user facing. That means being careful with deps)

[asinghvi17]

xref #314

Conclusion is that we remove GB but keep StaticArrays and CoordinateTransformations. Maybe CoordTrans needs a Base package or Interface package that defines types, since that's all I personally care about.

[rafaqz]

Yeah, Rasters has CoordTrans in an extension, it's not a core use case and so heavy for what it does. Would be good to do that here too

[asinghvi17]

Unfortunately we kind of need it for UnitSpherical. Better to fix at the source.

[asinghvi17]

CT only depends on LinAlg and StaticArrays both of which we need here, so it'd be kind of pointless to remove it IMO...I might just refactor it into a lightweight interface package, though.