-
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
ambiguities in included modules #77
Comments
I just came here to ask about this. Ideally all upstream packages from mine could fix any ambiguities, but in practice there's a lot of overhead in trying to enforce this. |
I found a hack for this. First I run with Aqua._test_ambiguities(
Aqua.aspkgids(MeasureBase);
exclude = [LogarithmicNumbers.Logarithmic]
) In this case, This is still not great, because,
|
Thanks for the info. It works. I made some trial-and-error exploration based on it and found that the following code works. using Aqua
Aqua.test_all(SimilaritySearch, ambiguities=false)
Aqua.test_ambiguities(SimilaritySearch)
It is a bit less manual but also could still have some issues. The first one is that, from my understanding, these calls should have identical results to the whole test Using Aqua 0.5 |
Looking a bit more at the documentation, I think the issue comes with the default arguments to This also works Aqua.test_ambiguities([SimilaritySearch, Core]) This fails Aqua.test_ambiguities([SimilaritySearch, Core, Base]) |
Given how much people are extending stuff in |
It is usually a waste of performance time also to include Core and Base explicitly now, since they will exclusively add ambiguities that are not from the package itself (which is already listed) |
fwiw a few data points I encountered today:
|
In addition to all that was said, I'd like to point out that
That said, the problem seems to be caused by
|
It is actually actively counter-productive now (causing this issue), but it used to be required for the test to function at all. |
@vtjnash OK... So, what changed that made it go from "used to be required for the test to function at all" to the current state? Were those changes in Aqua.jl? Or changes in Julia? Or something else? |
What's the current recommendation for testing for ambiguities in my package only? This?
|
There unfortunately currently is no way to test only your package for ambiguities. (as far as I know) |
For more details, I would ask @vtjnash to elaborate a bit. |
I just stumpled on this issue trying to add Aqua to a package I'm developing, that makes use of JuMP.jl. I do not depend on (or make use of) @testset "Aqua.jl" begin
Aqua.test_all(MyPackage; ambiguities=(exclude=[], broken=false, recursive=false))
end it fails with ambiguities like
even though I set Is there any way to ignore ambiguities from specific modules (similar problems occur for I'm currently using @testset "Aqua.jl" begin
Aqua.test_ambiguities(MyPackage)
end which works as a workaround, but I'd much rather manually exclude certain modules that I know of to be failing as soon as |
I am trying to use Aqua in my package (
SimilaritySearch
). I followed the documentation fortest_all
and found some ambiguity errors inStatsBase
. It reports and suggests some fixes. It stops the tests and reports. Everything is fine, but the possible errors are in theStatsBase
package that I use, not in mine.Is there a way to avoid checking for ambiguities in included modules? I searched the documentation and didn't find a way to skip crashes due to external packages. In particular, there is an option to avoid checking submodules; I supposed that this is not the same case.
I suppose this error will appear in other packages, but I just test with mine (I am using Julia 1.7.2, Aqua 0.5.5)
The text was updated successfully, but these errors were encountered: