write_stan_json and to_stan_json to rstantools?

[avehtari]

CmdStanR has write_stan_json(). BridgeStan could use that, too. In addition, BridgeStan would benefit from a to_stan_json() function that would not write to file, but just return a string. I made an issue to bridgestan https://github.com/roualdes/bridgestan/issues/202, but @WardBrian suggested putting it somewhere else, and maybe rstantools would be appropriate?

[jgabry]

The only issue I can think of with putting it in rstantools is that then cmdstanr would need to add a dependency on rstantools just to use this one function. @andrjohns what do you think?

[WardBrian]

in Python I put this in a brand new package I called (creatively) “stanio”

[avehtari]

Any further thoughts on this? I'm fine adding to_stan_json() to any package, but we need a decision on where to put it

[WardBrian]

I think for BridgeStan we would not really be willing to take a dependency on rstan or rstantools. It would be nice if it was in its own small package, or if we want to keep the number of CRAN submissions down, something backend agnostic (posterior? It doesn't quite fit I guess)

[andrjohns]

I think there's definitely a need for a backend-agnostic package for Stan-related utilities. I'd also be fairly invested in this since it would simplify a bunch of things I want to do for the StanEstimators package, so I'd be fine to take the maintainership for CRAN.

I can join the next Stan gathering meeting and we can chat it through then?

[WardBrian]

Sounds good