-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
deprecating MCMCDiagnostics.jl in favor of this package #41
Comments
We would of course welcome this and proposed something similar in tpapp/MCMCDiagnostics.jl#9 .
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). |
Thanks. I am happy to transfer the name now if you still need it. |
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? |
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. |
Done: I deprecated and archived MCMCDiagnostics.jl in favor of this package. |
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.The text was updated successfully, but these errors were encountered: