-
Notifications
You must be signed in to change notification settings - Fork 37
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
ImageCore warning needs fixing (by using XRGB and RGBX) #235
Comments
I tracked this down to these lines in libmagicwand.jl
It's the subtypes call that's throwing this deprecation error. That's in InteractiveUtils.jl If I replace this by just listing out the types...
Then it passes tests and doesn't throw this warning. |
Maybe @timholy or @johnnychen94 may need to chime in here. |
Here's the issue...
This shows...
|
So it seems like subtypes should check Base.isdeprecated before isdefined, but this might cause all sorts of other issues :) |
Is removing support for old versions of ImageCore sufficient to fix this? |
I'm getting this on the latest ImageCore (v0.10.2) with Julia 1.11... I think the only way to fix this is to avoid the subtypes call (i.e. hardcode the list of colors...) or adjust the subtypes function. |
Ah - so maybe leave this as is here and we can see if ImageCore can fix the problem? Running
|
That will still cause this issue though. While I won't claim to get this exactly right, I believe...
creates symbols/names for the deprecated bindings with an alias to their new type. Whenever So I actually think the right fix is to switch the order of checking things in subtypes. (You can't be deprecated unless you are defined, so I conjecture it's fine to check them in the other order...) So the ways to fix this are:
|
So, if we remove the deprecated bindings, we then need to make sure the key packages work fine (and remove old compat bounds). That seems reasonable to do. |
Okay, there may be another culprit here. I was testing my hypothesis to try and isolate that this was really the issue. And I couldn't reproduce it ... until I threw Reexport into the mix. So I think this is related -- simonster/Reexport.jl#42 After playing around with this a bunch, I think Reexporting a package with a deprecated binding is causing the issue here. Here is package 1:
and test case:
which outputs:
Now here's package 2
When I run the same test cases on that one:
|
Okay, here's the difference between the two scenarios, where I use my Module 1: The one that doesn't use Reexport
Module 2 with Reexport
So the difference is that using Reexport will export the binding for the type in the deprecated binding, even though it isn't exported by the parent module. |
@ararslan Since you are involved with Reexport and the issue above, can you see if anything jumps out at you? I'm trying to see find any hints. The short scenario is: I would have expected names(ImageMagick) to not include MyOldType since it isn't exported by InternalModule. But it does when using Reexport. This holds even when I replace This occurs because |
In case you want to see the same thing without Reexport, the Reexport code for this case expands to:
This doesn't trigger a deprecation warning because you are apparently allowed to export non-defined symbols. But this seems to create the MyOldType symbol in the ImageMagick module whereas just
does not. (Symbols/names must be lazily created as they are used?) |
More testing... the MyOldType isn't even marked as deprecated in the ImageMagick space (in the examples above...)
|
After carefully reading the discussion in I think the best fix is actually to do this in subtypes()
Everything else leaves the issue there and just patches around it. |
Great sleuthing! :) I agree, that seems like a good solution. |
Great work @dgleich. We should just remove those deprecated bindings, but the last time I pushed a breaking change to Color*.jl it was 3 days of tedious work to get JuliaImages updated with new releases (bump version, wait for CI, merge, register, and then go on to the next package in the dependency chains). I have plans to drastically reduce this by switching to a monorepo, but will need to find a block of dedicated time to do that. |
I'm happy to help out updating all the packages. Let's get it done! And perhaps we can even see if others can help. |
I think we should go ahead and register the new version of ImageMagick.jl first and then apply the deprecation fix discussed here and go through the ecosystem. |
Sounds good to register a new package, but wait for one more commit.
|
cc @aviatesk |
I merged this so that we can carry on with the plan with step 2. I assume we need to release a new minor release for ImageMagick.jl and then go ahead updating the rest of the ecosystem. |
Thanks for JuliaGraphics/ColorTypes.jl#312. It occurs to me that this one may not be bad: over time we tried to centralize as much color-related importing in ImageCore. And since these have been deprecated a long time, this might be an easy one. |
ColorTypes.jl 0.12 and Colors.jl 0.13 are now released. |
Thanks @ViralBShah !! |
The next package to tag is ColorVectorSpace.jl but it needs a little bit of maintenance: JuliaGraphics/ColorVectorSpace.jl#196 After which, we should be able to tag ImageCore.jl. |
Another update: I contributed a pull request to the subtypes function too in InteractiveUtils.jl here... JuliaLang/julia#56306 |
We have this warning now which would be nice to fix.
The text was updated successfully, but these errors were encountered: