Check for piracy and ambiguity in extensions

[aplavin]

Currently, Aqua doesn't check package extensions for piracy and ambiguity at all. Not sure how difficult that is, but would be nice to extend these checks to extension code.

[lgoettgens]

Could you point me to a rather small package with package extensions for me to test my ideas with?

[aplavin]

Any package with extensions, not necessarily with piracy/ambiguity issues? Then take eg https://github.com/JuliaObjects/ConstructionBase.jl - small and very popular one.

[lgoettgens]

Thanks! Yes, any package works, as I will add my small piracies/ambiguities myself anyway in a dev'ed version anyway.

After digging into it for some time, julia Base is not providing many helper functions. In the upcoming days, I will try to use some julia internals to test package extensions as best as possible (see https://github.com/JuliaTesting/Aqua.jl/pull/162).

[lgoettgens]

What should I implement?

i.e. What should be tested and semantics of already defined terms.

Piracy

• Adding more functions / methods with an extension does not remove any type piracy. -> Only test with all extensions loaded.
• Extensions may behave exactly as the base package (w.r.t. ownership)

  If one considers PlottingContourExt as a completely separate package, it could be argued that defining Plotting.plot(c::Contour.ContourCollection) is type piracy since PlottingContourExt owns neither the method Plotting.plot nor the type Contour.ContourCollection. However, for extensions, it is ok to assume that the extension owns the methods in its parent package. In fact, this form of type piracy is one of the most standard use cases for extensions. Source

• Functions only occurring in an extension (and not in the base package) should be considered as well, as they may pirate some dependency.

Ambiguities

• Adding dependencies and/or extensions may lead to more ambiguities. -> Add all weakdeps needed for a given extension all at once.
• If a package has $n$ extensions, each of the $2^n$ combinations of extensions may have different ambiguities. -> Choose some defaults and give the user the possibility to add additional combinations.

As a default, I propose the following $n+2$ combinations:

• no extensions, only the base package
• all extensions
• for each extension, only add that single extension

This should cover most cases, while still only needing a linear number of testruns.

What do you think @aplavin @fingolfin? In particular about the defaults for ambiguities?