Conversation
|
Pinging @bgoodri for the |
WardBrian
left a comment
There was a problem hiding this comment.
The overall approach seems prudent and sound.
Two questions:
- Do any of the affected packages use
#includes? Are those already processed by the time the canonicalization would happen? - Why 2.32? I believe 2.33 would still work, and had a few other improvements that might benefit pretty printing (though it's been a while, maybe they're the same in that regard)
Yeah, it uses the
Pretty much just because I just copied the |
|
Sounds good to me |
|
Reverse-dependencies check with this rstantools branch plus CRAN 2 install failures: |
|
Thanks @andrjohns, looks good to me. @bgoodri? |
|
The majority of the revdep test failures were caused by Stan's Patching that out of the EDIT: Down to three failures: https://github.com/andrjohns/rstan/actions/runs/29574108492#summary-87877836657 |
|
There are now only four packages showing install/test failures with CRAN
The only one I haven't quite figured out yet is the |
|
Awesome, thanks @andrjohns! |
|
Fixed up the
For
@bgoodri @jgabry how did you want to handle the submission process? Should we submit |
|
All reverse-dependencies for @jgabry happy for this to go CRAN? Then all is clear for @bgoodri to submit |
|
Awesome, yeah I'm happy for this go to CRAN! Let me know when you submit and I'll keep an eye out for the CRAN email so I can confirm the maintainer change. |
| ) | ||
|
|
||
| # Additional deprecations not covered by 2.32 stanc3 canonicalise | ||
| stan_post_process <- list( |
There was a problem hiding this comment.
These are going to run every time rstan_config() runs, right? For example, for survstan:
first run: offset -> offset_par
second run: offset_par -> offset_par_par
There was a problem hiding this comment.
For the CRAN revdep workaround this probably isn't an issue, but I think this would be a problem when any package developer locally runs rstan_config more than once.
We actually have a test for this, but it doesn't catch this because it's using a fake RStanTest package, not one of the packages in stanc_exceptions: (
rstantools/tests/testthat/test-rstan_config.R
Lines 83 to 96 in e03b02a
|
|
||
| # rewrites stanmodels.R reflecting current list of stan files | ||
| .update_stanmodels <- function(pkgdir) { | ||
| .update_stanmodels <- function(pkgdir, pkg_name, is_excepted) { |
There was a problem hiding this comment.
I think is_excepted is actually ignored, so e.g. every future survstan will get the offset_par -> offset change instead of forcing them to change in the future, which I think was the original intent
There was a problem hiding this comment.
I see your previous commit that removed using is_excepted because of disbayes mangling, which makes sense, but I think we need to keep it for the other packages.
| stanc_process <- utils::getFromNamespace("stanc_process", "rstan") | ||
| sapply(stan_files, function(stanfile) { | ||
| model_code <- stanc_process(stanfile) | ||
| model_code <- ctx$call("stanc", "dummy", model_code, as.array("print-canonical"))$result |
There was a problem hiding this comment.
Do we need to check $errors in addition to $result?
The main blocker for the
rstan-> CRAN transition is the number of packages that still have not updated their deprecated syntax, despite plenty of notice.To workaround this, the current PR adds an 'exception list', where specified packages at specified versions (currently only the broken reverse-dependencies) have their Stan code canonicalised/updated at installation-time for compatibility with stan 2.36+.
If a version for one of these packages changes, then the automatic canonicalisation does not occur and the author would be required to update their Stan syntax for their package to build.
This allows for a compromise where abandoned/unmaintained packages are no longer blocking
rstanupdates, while any packages still receiving active development will be forced to update their syntax once a new version ofrstanis published.As part of testing this, I've created an
rstanbranch at the 2.39 release point here: rstan@v2.39.0 and added handling for the RNG changes (ecuyer->mixmax).With these
rstantoolschanges and thatrstanbranch, I'm able to build all CRAN reverse-dependencies under both combinations (2.32 rstan + 2.39 StanHeaders) and (2.39 rstan + 2.39 StanHeaders) except for two (tmbstanandrmdcev)