Request to package developers: Please eliminate ambiguities with Base

Community
,
1

It’s often frustrating when you want your package to depend on an amazing package A, but doing do introduces ambiguities in Base functions that A has not eliminated. There are several packages that I’ve come across recently with this issue:

The way to avoid this is often simply to put in

@test isempty(Test.detect_ambiguities(Base, Core, YourPackage))`

in your package’s runtests.jl after you’re done resolving the existing ones.

Methods ambiguities should be something that packages try to avoid. It’s possible that two packages A and B extend Base methods in a way that is ambiguous when one imports them both in the same session, and such issues might be harder to anticipate as a developer. However there’s no reason why A and B shouldn’t eliminate standalone ambiguities.

15 Likes
2

Is the following good or bad for a package? I would rather not put this into my runtests.jl.

julia> Test.detect_ambiguities(Base, Core, Hecke)
ERROR: StackOverflowError:
Stacktrace:
 [1] _methods_by_ftype at ./reflection.jl:858 [inlined]
 [2] _methods_by_ftype(::Any, ::Int64, ::UInt64) at ./reflection.jl:855
 [3] isambiguous(::Method, ::Method; ambiguous_bottom::Bool) at ./reflection.jl:1308
 [4] detect_ambiguities(::Module, ::Vararg{Module,N} where N; imported::Bool, recursive::Bool, ambiguous_bottom::Bool) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Test/src/Test.jl:1446
 [5] detect_ambiguities(::Module, ::Vararg{Module,N} where N) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Test/src/Test.jl:1421
 [6] top-level scope at REPL[7]:1

P.S.: Tried three packages, got three times the StackOverflowError.

2 Likes
3

This is interesting, I’ve not encountered this before. Perhaps it’s worth reporting this issue. I can reproduce this as

julia> using Hecke

julia> Test.detect_ambiguities(Base)
ERROR: StackOverflowError:
Stacktrace:
 [1] _methods_by_ftype at ./reflection.jl:841 [inlined]
 [2] _methods_by_ftype(::Any, ::Int64, ::UInt64) at ./reflection.jl:838
...

Edit: filed an issue

1 Like
4

Thanks!

5

It’s often frustrating when you want your package to depend on an amazing package A , but doing do introduces ambiguities in Base functions that A has not eliminated.

If there’s no type piracy, then using package A cannot interfere with your usage of Base, unless you’re actually using the types from A, in which case it’s a “regular ambiguity”. Is that what you’re talking about?

2 Likes