CompatHelper: bump compat for "ColorTypes" to "0.10"

[github-actions]

This pull request changes the compat entry for the ColorTypes package from 0.8, 0.9 to 0.8, 0.9, 0.10.

This keeps the compat entries for earlier versions.

Note: I have not tested your package with this new compat entry. It is your responsibility to make sure that your package tests pass before you merge this pull request.

[kimikage]

As you know, ColorTypes v0.10 and Colors v0.12 are coupled. Therefore, PR #127 or PR #128 should not be merged separately.

ColorVectorSpace is not compatible with ColorTypes v0.10 "now" (cf. JuliaGraphics/ColorTypes.jl#160)

I will not make a decision on whether to keep or drop the support for ColorTypes v0.8 and v0.9 using if statements.

FYI, the issue #124 is independent of the ColorTypes update.

[johnnychen94]

I will not make a decision on whether to keep or drop the support for ColorTypes v0.8 and v0.9 using if statements.

Out of curiosity, what if statement should be used in such cases? I did something like JuliaImages/ImageTransformations.jl#89 but it appeared to have precompilation issues.

[kimikage]

I don't think this is the same problem with JuliaImages/ImageTransformations.jl#89, i.e. the obvious type piracy.
This is purely a matter of agreement between ColorTypes and ColorVectorSpace.

[johnnychen94]

Sorry that I was confusing.

For the ColorTypes/ColorVectorSpace agreement. In ColorVectorSpace, is there a way to check if the specific method isless(::AbstractGray, ::AbstractGray) is defined in ColorTypes? The way I used in JuliaImages/ImageTransformations.jl#89 does this via InteractiveUtils.methodswith, but it's likely to hit a precompilation issue.

If we keep two copies of isless(::AbstractGray, ::AbstractGray), except the annoying incremental compilation warning, it seems not breaking anything as long as the two definitions are the same. In this sense, ColorTypes is still "compatible" with ColorVectorSpaces even with JuliaGraphics/ColorTypes.jl#160

P.S. I did that because I can't find a way to get the version of Interpolations.jl (In this issue, it's ColorTypes)

[kimikage]

If this is really an issue, I suspect we need to add a Requires dependency to Interpolations and put this in a @require block there.

Originally posted by @timholy in JuliaImages/ImageTransformations.jl#89

Have you overlooked "If this is really an issue"?

[johnnychen94]

I will not make a decision on whether to keep or drop the support for ColorTypes v0.8 and v0.9 using if statements.

If I understood your words correctly, you were saying something like this:

# in ColorVectorSpace
if COLORTYPES_VERSION < v"0.10"
    Base.isless(a::AbstractGray, b::AbstractGray) = isless(gray(a), gray(b))
end

But the issue is that we don't know the version of ColorTypes.

[kimikage]

I think it's better to clarify what "you" call "precompilation issue". If it is really a problem, what happens when ColorTypes goes downgraded?

[johnnychen94]

Ideally, we want isless(::AbstractGray, ::AbstractGray) has one definition in ColorVectorSpaces (either from ColorTypes or ColorVectorSpaces).

If there're two definitions, then julia would complain about incremental compilation. I believe that's the reason you say "ColorVectorSpace is not compatible with ColorTypes v0.10".

A feasible solution is: remove the isless in ColorVectorSpace and set the new ColorVectorSpace compatible to only ColorTypes 0.10. The only issue is by doing this we probably make the package less compatible with others -- this might be or might not be an issue. But from a package maintainer's point, we need to take this into consideration.

So we need to find a way to not throwing incremental compilation warning, and to still keep compatibility to old ColorTypes. That's where I came up with the codes in
JuliaImages/ImageTransformations.jl#89

if !is_this_isless_method_defined_in_ColorTypes()
    Base.isless(a::AbstractGray, b::AbstractGray) = isless(gray(a), gray(b))
end

But this is actually a runtime check; correct me if I understand it incorrectly, during precompilation, this line might be evaluated before ColorTypes is loaded, and if that's the case, we'll get two definitions of the same method. --> incremental compilation warning again.

Even it's evaluated after the loading of ColorTypes, I don't think it is safe to rely on this level of implementation details -- unless the precompilation order is documented somewhere.

So one solution is to move this patch line to __init__, where we clearly know the loading order. As a tradeoff, we don't have the precompilation gain. --> However, I don't think this would be a big deal because this only affects old ColorTypes packages.

Precompilation is still some kind of black box to me, so please correct me if I misunderstand the problem. I'm not good at English neither, I hope I've stated my problem clearly...

[timholy]

Precompilation is still some kind of black box to me

There are certainly elements I don't understand but let's try to open the box a bit. The key is that it's really just ordinary Julia but it's performing "incremental compilation": it switches into a mode where, as it's parsing its way through a *.jl file, it logs definitions of modules, constants, types, macros, and functions to a second file (the *.ji file). Were it not for one issue---also storing results from type inference, to save compilation time later---there would be no need for precompilation, since the *.jl file itself is a perfectly fine format for describing these quantities. But as soon as you need to add extra information, you need a new file format, hence the *.ji file.

The key feature that determines precompile safety is whether decisions made when it does this logging apply to any new session. So, for example, if I had a top-level construct

if isdefined(Main, :usecuda) && Main.usecuda
    f(x) = ... some cuda implementation
else
    f(x) = ... some CPU implementation
end

this would not be precompile-safe because the outcome depends upon whether my current session has defined a variable usecuda and its particular value. Likewise if I write a package that does something sneaky and deletes a method from another package and replaces it with a new version, it's not safe because once you allow deletion then things can become load-order-dependent.

this line might be evaluated before ColorTypes is loaded

Not possible if you've said using ColorTypes above it. Which you'd have to have done even if this weren't a precompiled file, just so those types are defined, and now hopefully you see that it's no different for precompilation.

Since precompile files require an exact version match of all package dependencies, the outcome of the particular test you're wondering about is statically-decidable. So it doesn't present a threat to precompilation. I haven't tested, but you should be able to use hasmethod and, if necessary, put a @static around the block (though I don't see why it would be necessary).

[timholy]

Should also add: the role of the __init__ function is to do any work that you'd need to perform again when loading the package. A good example is my PR JuliaLang/julia#35094 which you commented on; registering a callback is the kind of thing that won't be preserved across Julia sessions, so you have to do it from the module's __init__ function. Julia will run __init__ after the module finishes loading.