Restore GeoInterfaceRecipes as empty stub package#213
Conversation
There was a problem hiding this comment.
This seems correct. What do you think @asinghvi17? This is the old state https://github.com/JuliaGeo/GeoInterface.jl/blob/v1.4.1/GeoInterfaceRecipes/README.md, and the package was removed in 1.5 via #198.
| name = "GeoInterfaceRecipes" | ||
| uuid = "0329782f-3d07-4b52-b9f6-d3137cf03c7a" | ||
| authors = ["JuliaGeo and contributors"] | ||
| version = "1.0.3" |
There was a problem hiding this comment.
Is it a breaking change to delete the macro? Maybe we should offer at least a stub macro that throws a deprecation warning?
Otherwise this should be v2.0 technically.
Other than that, this looks good.
This could also just forward the expression to the macro that is now in GeoInterface which would be a non breaking change
There was a problem hiding this comment.
Hmm, I see now this is missing the RecipesBase = "1" dependency. The idea is, as soon as you load this package, the extension is guaranteed to trigger (which currently causes the compilation warning we're trying to prevent). So this should be non-breaking.
There was a problem hiding this comment.
Probably need to update the compat to julia 1.10 so extensions are guaranteed.
There was a problem hiding this comment.
What I mean by breaking change is that this macro will no longer exist
So this package would have to at least load RecipesBase (via using) and provide a macro that doesn't error when used in this way to be non-breaking (what the macro does is then kind of immaterial although it would be great to forward it to GeoInterface.@enable_plots)
There was a problem hiding this comment.
Btw you can invoke macros as functions so long as you provide the file and line information
There was a problem hiding this comment.
Good point, using RecipesBase + a stub macro it is. I don't think you can forward though without getting into overlap again, I rather keep it non-functional.
3 participants
Summary
Fixes #200
Test plan
🤖 Generated with Claude Code