I want to ensure that my package, CliffordNumbers.jl, interoperates with Unitful.jl, and that parametric types dependent on both packages (like Quantity{<:AbstractCliffordNumber}) have operations defined on them consistently (such as the wedge product, ∧).
However, I’ve found myself wondering whether the package extension should belong to CliffordNumbers.jl or Unitful.jl. On one hand, CliffordNumbers.jl provides a numeric type, and I think it makes more sense for Unitful.jl to own the extension, since it is what wraps the AbstractCliffordNumber instances in its own AbstractQuantity type. On the other hand, I’m the one working on support for this feature and I own CliffordNumbers.jl.
Outside of considerations of who is doing the development: is there any reason to favor having the extension reside in one package over the other?
My understanding is that this kind of social and not technical aspects defines the best location for the extension. From the technical standpoint, the extension will be loaded whenever both packages are loaded anyway.
Taking it to extremes, separate developers of the packages B, C, D, E, etc can unilaterally make extensions with a package A (though collaboration would help in some ways), and it seems unrealistic for the developer of package A to absorb all those extensions into their own development. They might not have the knowledge or desire to work on most of the extensions, either.
My usual heuristic is that the extension goes in the least popular package. If you’re developing a slightly specialized project and you need to support, say, Dual numbers, then it’s not the responsibility ForwardDiff.jl to accommodate you, because everyone else is already using it. So here I would recommend extending CliffordNumbers.jl because it is less central to the ecosystem than Unitful.jl (judging by download numbers).
I do second @gdalle s general idea with the specialised package having an extension to the popular/generic one.
But it could even be both ways. Say A has a type A.C which is very well-suited to extend a method as B.b(::C), to in A there is a ExtB extension.
At the same time the type B.D might be well-suited to extend a method to A.a(::D) so – maybe even being unaware of ExtB the developers of B might write a ExtA extension as well.
This might even git well if for example both packages are equally popular or both packages decide to “not to bother the other one” caring for an extension of the other package concerning ones own types.
But sure, this is still a social thing to agree upon.
There’s an easy thought experiment one can do. If the extension would have been an independent package, who would have created and maintained it? If the answer coincides or significantly overlaps with the maintainer(s) of one of the packages, that’s where the extension should go.