deprecating MCMCDiagnostics.jl in favor of this package

[tpapp]

Instead of maintaining a parallel package, I am considering deprecating https://github.com/tpapp/MCMCDiagnostics.jl in favor of this package. This would make much more sense, and I could just contribute code here instead. I am opening this issue to ask the opinion of package devs about this.

What allows me to do this is the representation-agnostic design of the API, ie that functions just take an <:AbstractArray. I would like to know if this is intended and likely to remain so.

[sethaxen]

Instead of maintaining a parallel package, I am considering deprecating https://github.com/tpapp/MCMCDiagnostics.jl in favor of this package. This would make much more sense, and I could just contribute code here instead. I am opening this issue to ask the opinion of package devs about this.

We would of course welcome this and proposed something similar in tpapp/MCMCDiagnostics.jl#9 .

What allows me to do this is the representation-agnostic design of the API, ie that functions just take an <:AbstractArray. I would like to know if this is intended and likely to remain so.

Yes, this will remain the case. Other packages (e.g. MCMCChains and ArviZ) are expected to overload these methods to provide support for custom inputs. It's possible we will at some point change the expected order of dimensions (see #5).

[tpapp]

Thanks. I am happy to transfer the name now if you still need it.

[sethaxen]

Thanks! I can see upsides and downsides to transferring the name, and I'm not certain how they balance. Upside is simpler name and less likelihood a user accidentally loads your package when they want ours. Downside is I'm guessing this would require some non-automated work at General, and if a user really does want your package, I don't know how they would be able to load it from the registry in the REPL.

@devmotion what do you think?

[tpapp]

FWIW I think that the package name ending in Tools is more expressive for the purpose of this package, and retiring MCMCDiagnostics and pointing people here would be the simplest.

[sethaxen]

FWIW I think that the package name ending in Tools is more expressive for the purpose of this package, and retiring MCMCDiagnostics and pointing people here would be the simplest.

After more thought, I agree this is probably the best way to go.

[tpapp]

Done: I deprecated and archived MCMCDiagnostics.jl in favor of this package.