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 |
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)