-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add package extension on RecipesBase #143
base: main
Are you sure you want to change the base?
Conversation
macro enable(typ) | ||
esc(expr_enable(typ)) | ||
end | ||
|
||
# Compat | ||
macro enable_geo_plots(typ) | ||
esc(expr_enable(typ)) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand correctly, this is no longer available as a "name" to import from GeoInterface / some other package. Do you want to keep the package GeoInterfaceRecipes and just load that code path as the extension?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The macro is exported by GeoInterface now, so it should be usable. I've answered your other question in the general comments.
This at least fixes #110 (for people that forget to do I still have to check whether this can be used to deprecate GeoInterfaceRecipes completely, and how that would work. Essentially, as soon as a package uses RecipesBase, it would trigger this package extension, but if it triggers in an extension on RecipesBase, then the macro would not be available. |
Co-authored-by: Anshul Singhvi <anshulsinghvi@gmail.com>
@@ -0,0 +1,151 @@ | |||
# Convert coordinates to the form used by Plots.jl | |||
_coordvecs(::PointTrait, geom) = [tuple(coordinates(geom)...)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we put all these functions in the extension and just leave the stubs here to extend in the extension?
I'm also not sure about defining |
Yeah the other solution that I considered is just duplicating the code. I'm pretty unsure about include, as it's a standalone package, even though it's in a monorepo here right? |
Can we just do the Then we don't have the circular dep on the sub-packages but we can use the same code and not break anything. It does end up using a bit more compilation and memory as its the same code used twice, but I think that's ok. Edit: we may need to move code out of the modules into separate files for this to work. |
GIMakieExt is circular but RecipesExt could work |
Oh of course because Makie depends directly on GeoInterface.jl via GeometryOps.jl, forgot for a second. Maybe... could we just move the GeometryBasics.jl geointerface code to an extension in GeoInterface.jl? We need to solve this somehow |
I think we tried to in a GeometryBasics PR but I ended up not wanting to do that for some reason. We can in theory just have Makie depend on GeoInterfaceMakie too... |
This moves all the plots related code, including the macro(!) into GeoInterface. This now works:
Since we now export the macros, I think the existing GeoInterfacesRecipes continues to work, even though it's now empty.