-
-
Notifications
You must be signed in to change notification settings - Fork 21
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
Auto-format Stan models during rstan_config()? #113
Comments
We can handle this automatically in the experimental version of RStan by defaulting |
I don't think we should do it |
@jgabry based on your experiences with CRAN, if we update |
And to clarify that I was thinking this would only be added after 2.31 is on CRAN (assuming the 2.26 -> 2.31 transition is minimal) |
I like this idea, but I might be overlooking a reason not to do this. @bgoodri What do you think?
If I understand correctly, your idea of running the auto-formatter in rstantools would avoid this, right? If we don't auto-format but still add a warning to stanc that causes failures in ~100 packages then that would likely be frowned upon by CRAN even if we technically comply with their policy of giving developers enough advance notice. That said, if we give developers time to update their packages and they choose not to, at some point that's on them and not on us and we'd be in compliance with CRAN policy, so we could maybe push forward anyway. Not ideal, but a possibility. |
When running the reverse-dependency checks for
rstan
2.31 with thestanc3
branch for erroring on expired deprecations, the majority of dependencies are failing (mostly due to the array syntax).Rather than requiring another extensive round of patches and submission delays, should we just run the stanc auto-formatter during the
rstan_config()
call? We can then also be opening issues and contacting the relevant maintainers to say that they should be updating their models, but the actual update could still progress in the interim.Note that there's still some discussion on when the deprecations should be made into warnings, but it's still worth putting a plan together early.
Tagging the relevant players for input: @hsbadr @jgabry @bgoodri
The text was updated successfully, but these errors were encountered: