Controlled type-piracy

[tkf]

Quoting discussion with @timholy in JuliaMath/IntervalSets.jl#56 (comment)

Off topic, but I think it'd be nice if Pkg.jl helps doing type-piracy in more controlled manner. Some metadata fields like extending (specifies pirated packages) and conflicting-with would be nice.

I had the same thought. There might be ways of getting the same behavior as conflicting-with now (both packages deliberately exporting the same function), and it's worth asking exactly what purpose these serve and how they get integrated into the ordinary user experience (warnings? errors? just documentation? how do people know to go look?), but Pkg does seem to be the right place to declare these things and worth mulling over what the behavior would actually be.

[tkf]

how they get integrated into the ordinary user experience (warnings? errors? just documentation? how do people know to go look?)

@timholy I think there should be at least a warning if packages specified by conflicting-with are installed. Maybe it even makes sense if this becomes an error during add. But actually there is no harm until those packages are loaded so I'm not 100% sure about this.

[KristofferC]

Would conflicting-with be the same as declaring compatibility with no versions of that package?

I am not sure it is a good idea to introduce this other level of compatibility. Something like this opens a lot of questions and it's applicability seems to be quite narrow.

[timholy]

Yeah, I'd really want to understand exactly what it does and what problems it solves.

[tkf]

Would conflicting-with be the same as declaring compatibility with no versions of that package?

This is a very clever use of version bound! But I think it requires Pkg to treat compatibility information of non-deps packages. Reading #1285, I'm guessing you prefer to avoid doing this. (But, as a user, I think this would be a nice feature and that's why requested it before #1179)

I just realized that a warning system for conflicting-with can be implemented at as a third-party package based on Base.package_callbacks. So I guess it'll be developed if it is necessary. The API may look like

using ConflictWarnings

function __init__()
    conflicting_with(
        PkgId(..., ...),
        PkgId(..., ...),
        ...,
    )
end

As for extending metadata, I was thinking that it can be used to show list of packages that modifies the behavior. For example, it can be used in pkg> status output

(v1.3) pkg> st IntervalSets
    Status `~/.julia/environments/v1.3/Project.toml`
  [8197267c] IntervalSets v0.3.2 [`~/.julia/dev/IntervalSets`]
Extended by:
  [d1acc4aa] IntervalArithmetic v0.16.1

when IntervalArithmetic has metadata (say)

[extending]
IntervalSets = "8197267c-284f-5f27-9208-e0e47529a953"

But then I realized that it can also be done in a third-party package by scanning the method table and it would produce more accurate result.

So, I'm closing this now as it turned out almost everything I thought that would be useful can be done in third-party packages.