Rstan -- maintenance / future prospects?

Does this include packages which depend on both rstan and StanHeaders (i.e. most packages) or only packages which depend only on StanHeaders i.e. OpenMx?

@hsbadr if the rstan + stanheaders formulation is still desired, wouldn’t an easy solution be to make them distinct, ie so that rstan doesn’t depend on stanheaders?

1 Like

Thanks @ahartikainen! I meant by RStan3 a new standalone package based on the experimental branch, which will make it easier to upgrade and release to CRAN while resetting the reverse dependencies (and removing StanHeaders dependency with bundled headers). It can take any name, but rstan3 is in sync with stanc3.

This is in the context of releasing a transition version of StanHeaders that works with the old version of rstan. If you maintain a package, test it with StanHeaders v2.26.2 (StanHeaders_2.26 branch) and the CRAN version of rstan.

That’s what I meant by RStan3. Packages that currently depend on rstan may be linking to StanHeaders too, which currently provides conflicting headers. If a new package isn’t desired, we’ll have to coordinate with the maintainers.

2 Likes

@Charles_Driver @jeffreypullin I’ve updated the source and binary packages for the transition. If you maintain a package that depend on StanHeaders, it’d be helpful if you can test it with the combination of StanHeaders v2.26.2 + rstan v2.21.2 and StanHeaders v2.26.2 + rstan v2.26.2.
You may install StanHeaders v2.26.2 using:

install.packages("StanHeaders", repos = c("https://mc-stan.org/r-packages/", getOption("repos")))

With just the stanheaders upgrade, I get a pile of errors building ctsem. Wouldn’t it be worthwhile including a test build of some of the packages using rstan in more complex ways, so we don’t go through the same back and forth as in January though? :) Can’t post error here (too large) so will add to the long issue on github…

StanHeaders 2.26.2 + rstan v2.21.2 works with rater (my package).

More warnings are shown however, and compilation does feel a little slower.

Do you have USE_STANC3 defined? If so, the C++ code is generated by stanc2 and you try to access the new incompatible headers.

Great! I think the main test here is to pass R-CMD-check for CRAN submission; that could be done by revdepcheck::revdep_check(). Then, we need to make sure that the transition won’t affect the subsequent upgrade of rstan.

1 Like

Ok. with -DUSE_STANC3 removed, then new stanheaders + old rstan is fine. But to get new stanheaders + new rstan working, I still require -DUSE_STANC3.

That’s exactly the purpose of USE_STANC3. The new version of rstan uses stanc3.

We don’t understand each other somehow :) I don’t see how the transition will work. If I patch ctsem so that it works with the new stanheaders and old rstan, it’s then broken when rstan gets upgraded.

Check the discussion here. You need to define USE_STANC3 only if (utils::packageVersion("rstan") >= 2.26).

Discussion didn’t help me. Sorry if I’m being slow. As a package maintainer, I am not in control of what utils::packageVersion("rstan") returns, yet it seems that you expect me to appropriately modify the package makevars.

I see. If you’re using GNU Make, you may add the following, or a variant of it, to the compiler flags:

$R_HOME/bin$R_ARCH_BIN/Rscript -e "cat(ifelse(utils::packageVersion('rstan') >= 2.26, '-DUSE_STANC3', ''))"

You’ll need to get just about every package using rstan to do this, you realise? My makevars has the following lines I couldn’t figure out a working variant of what you posted.

STANHEADERS_SRC = $(shell "$(R_HOME)/bin$(R_ARCH_BIN)/Rscript" -e "message()" -e "cat(system.file('include', 'src', package = 'StanHeaders', mustWork = TRUE))" -e "message()" | grep "StanHeaders")

PKG_CPPFLAGS = -I"../inst/include" -I"$(STANHEADERS_SRC)" -DBOOST_DISABLE_ASSERTS -DEIGEN_NO_DEBUG -DRCPP_PARALLEL_USE_TBB=1 -DUSE_STANC3
PKG_CXXFLAGS = $(shell "$(R_HOME)/bin$(R_ARCH_BIN)/Rscript" -e "RcppParallel::CxxFlags()") $(shell "$(R_HOME)/bin$(R_ARCH_BIN)/Rscript" -e "StanHeaders:::CxxFlags()")
PKG_LIBS = $(shell "$(R_HOME)/bin$(R_ARCH_BIN)/Rscript" -e "RcppParallel::RcppParallelLibs()") $(shell "$(R_HOME)/bin$(R_ARCH_BIN)/Rscript" -e "StanHeaders:::LdFlags()")

CXX_STD = CXX14

This version check should be worked out once and put into rstantools surely?

Isn’t that what the PR is doing?

Broadly, I think ‘we’ should aim for all packages which use rstan to use rstantools.

This affects the transition only and will be automatically applied for the packages that use rstantools. But, we’re also discussing a package with bundled Stan/Math sources which should fix all the mess without relying on the maintainers of reverse dependencies (they can take their time to switch to the new package, when/if it’s on CRAN).

1 Like

@Charles_Driver Replace -DUSE_STANC3 in PKG_CPPFLAGS; something like:

STANC_FLAGS = "$(R_HOME)/bin$(R_ARCH_BIN)/Rscript" -e "cat(ifelse(utils::packageVersion('rstan') >= 2.26, '-DUSE_STANC3', ''))"
PKG_CPPFLAGS = -I"../inst/include" -I"$(STANHEADERS_SRC)" -DBOOST_DISABLE_ASSERTS -DEIGEN_NO_DEBUG -DRCPP_PARALLEL_USE_TBB=1 $(STANC_FLAGS) 
1 Like

I think this is the ‘something like’ :)

STANC_FLAGS = $(shell "$(R_HOME)/bin$(R_ARCH_BIN)/Rscript" -e "cat(ifelse(utils::packageVersion('rstan') >= 2.26, '-DUSE_STANC3',''))")
PKG_CPPFLAGS = -I"../inst/include" -I"$(STANHEADERS_SRC)" -DBOOST_DISABLE_ASSERTS -DEIGEN_NO_DEBUG -DRCPP_PARALLEL_USE_TBB=1 $(STANC_FLAGS)

Yes, that’s it. I was suggesting without testing :)