-
Notifications
You must be signed in to change notification settings - Fork 24
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
Remove pyplot strong dependency #38
Conversation
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #38 +/- ##
==========================================
- Coverage 46.23% 45.59% -0.64%
==========================================
Files 8 10 +2
Lines 2109 2441 +332
==========================================
+ Hits 975 1113 +138
- Misses 1134 1328 +194 ☔ View full report in Codecov by Sentry. |
Julia LTS (1.4) fails because it does not know about extensions. I naively thought it would be kind of backward compatible, but it apparently is not... I will look into this |
I would suggest changing CI to only test Julia 1.6 and later as 1.6 was the last LTS |
The packaging documentation shows a way to move code into an extension while keeping backwards compatibility:
if !isdefined(Base, :get_extension)
include("../ext/ImageProjectiveGeometryPyPlotExt.jl")
end While this should work, we keep the strong dependency for older Julia<1.9. This keeps the CI complicated and requires projects that want slim dependencies to use at least Julia 1.9+. The alternative would be to only support new Julia versions, but given that 1.6 is the LTS, this is probably not a good idea... |
Sorry I couldn't come back to this yet. I'm not familiar yet with the Now that's assuming this is a small fix. Ideally I'd say we really make this a very "mathematical" package, move anything with plotting somewhere else (maybe keep on the same repo, although I'd guess it's easier for julia packages to keep it simple). Now there's just no plotting anywhere, and we retain support for older versions. |
include("geometry.jl") | ||
include("plotting.jl") |
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.
Shouldn't this include go now inside the extension module?
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.
Could be. I was thinking about allowing different plotting backends, as PyPlot can be quite tricky to set up, and I have used Makie recently, which worked quite well.
I guess my idea was to have some logic that defines the interface of the plotting (which functions need to be implemented) and decides which plotting backend to use - and also is more explicit if somebody tries to use one of the functions.
Looking at the docs again, I think we could also move it into the extension module.
I guess you do not care too much about plotting, so I could look into it and make sure, that all plotting backends have the correct interface.
src/plotting.jl
Outdated
function plotcamera(Ci, l; col=[0,0,1], plotCamPath=false, fig=nothing) | ||
ext = get_plot_backend() | ||
return ext.plotcamera(Ci, l, col, plotCamPath, fig) | ||
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.
Sorry for nitpicking, please configure your editor to add newlines at the end of files.
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.
Good point, not nitpicky at all.
src/ImageProjectiveGeometry.jl
Outdated
@@ -164,8 +164,8 @@ include("transforms3d.jl") | |||
include("ransac.jl") | |||
include("cornerfeatures.jl") | |||
include("utilities.jl") | |||
include("ransacdemo.jl") | |||
# include("ransacdemo.jl") |
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.
Maybe this could be simply included in the extension module as well (see next comment)
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.
yeah, maybe. It should go somewhere. I guess, we should add the move to the readme, as the demo would be only available if you take additional steps.
I'd like to try the package out first, but I'm thinking maybe we go ahead with this. Let me get this straight, this keeps compatibility with 1.6, even if CI breaks or whatever, and any 1.6 users might figure out what to do, correct? We merely gain a "new feature" on 1.9, and are able to ignore PyPlot in CI. I'm thinking this would look like and API change, and perhaps we should now bump a major version? Maybe not now, I guess we can finish the PR first and see if we want to make any other big changes. |
So this would make a shiny feature in 1.9+, where we have the state we want: plotting works if you manually add PyPlot. If you do not add PyPlot, then no plotting is happening at all and CI for example would be easier (if we do not want to test the plotting code) For everybody <1.9, a small change (see #38 (comment)) is required, that adds PyPlot as a normal dependency (again). Then, nothing is different from now. Moving the plotting out of the default functionality would warrant a version change I guess. So things I want to change before merging:
This will require CI to still set up Pyplot for the LTS Julia (1.6), which is still broken (see the other discussion). I hope I did not forget anything... Would you be ok with all that? |
- restore compatibility with Julia <1.9 by re-introducing the PyPlot dependency (will be ignored on newer Julia versions) and hard including the extension of weakdeps are not available - move ransacdemo.jl into the extension module - add to README.md how to get plotting back on new Julia - remove the plotting.jl stub, where the functions that extensions need to implement were declared.
Hey everyone, I put some more time into making this work and implemented the changes described above. This does not fundamentally change things, as tests are still broken for older Julia versions. But for Julia >=1.9, we do not need PyPlot anymore. As a next step, we could use Requires.jl to provide the same functionality, as is also mentioned in the Julia packaging docs. I initially did not like this solution, as it adds more dependencies, but the longer I think about it, the more I like it. The alternative would still be dropping support for Julia <1.9, but I do not want to decide this alone. What do you say? Best, Paul |
Based on https://pkgdocs.julialang.org/v1/creating-packages/#Backwards-compatibility this uses Requires.jl to bring the weak dependency feature to Julia <1.9
move plotting.jl back in... extensions cannot add new functions, so we already need to define them in a stub that raises an error. We should think about what to export here.
When using Requires and/or package extensions, the PyPlot dependency is not needed anymore. I guess I just forgot to take it out..
I personally see little problem with requiring Julia >= 1.9 especially if it makes package development simpler. |
By requiring a higher Julia version, the package extension mechanism will be available and can be used always (no need for Requires.jl anymore). This makes the implementation easier. The `get_plot_backend()` function is still contained to avoid method overwrite warnings. Usually, a package extension does type piracy and dispatches on a new type. We only have the demo functions, which cannot dispatch on the type. This now can be extended to different plotting backends (Makie for example), which in turn could be selected in the `get_plot_backend()` function.
Ok, I also see no problem in requiring a newer Julia version. If this is fine for everybody, then the latest changes should be fine:
The tests seem to be fine except for the coverage. The plotting functions are not tested, so coverage is not increased and the coverage of the diff is small. I would appreciate it if somebody could take a look at the resulting changes, to check if I missed something. Thanks and all the best |
Any comments on that? I would like to merge that to get it out of my head (and also simplify the testing for another package I am working on). If there are no objections, I would merge this soon. Best, Paul |
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.
Sorry to have held you up. I think it looks good to go. (Sorry about all my trailing spaces on so many lines of code!)
No worries, I was also busy and did not keep track. |
Yes I guess this should be a new release as a fair bit has changed. Perhaps also add a brief note to the README explaining the plotting changes and the need for Julia 1.9 or greater. |
I had already added some information to the README in the Installation section. Do you think this is sufficient? I can of course extend it a bit. |
What you have added to the README is fine. Sorry, I should have looked first! |
As discussed in #37 we could also move the plotting into an extension and make PyPlot a weak dependency. This PR tries this instead of commenting out all mentions of PyPlot.
It should be working well enough, two minor things remain:
nonmaxsuppts
to not plot the result to work in the default case without PyPlot availableransacdemo.jl
is still not ported, maybe I can get to it at some point@nlw0 what do you think about this?
Cheers Paul