asking for a friend … :D
We see a lot of people who work in industry at companies with policies of only allowing CRAN packages. There are two main reasons that CmdStanR is not on CRAN and is unlikely to be on CRAN in the future.
-
Putting a package on CRAN and then maintaining it on an ongoing basis is a lot of ongoing work. It also restricts what we can do. If we ever want to change anything, we have to make sure not to break any other package’s unit tests, which can test things like the spelling in error messages. It’s very hard to get funding to pay for software development in academia and @Jonah, @bgoodri, and @andrjohns, who are writing most of our R code, work at universities
-
I’m not convinced that putting CmdStanR on CRAN will help people at companies with restrictive policies. To run CmdStanR, you need to install the CmdStan executable. And CmdStan is not managed by CRAN (it’s not R, just C++). So any company that requires CRAN for safety and then allows CmdStanR to depend on an unregulated executable is clearly not thinking things through (wouldn’t be a first for security concerns at companies).
@saudiwin—Could you ask your friend (a) why they want CmdStanR on CRAN, (b) if they would be able to use CmdStanR given that it needs an executable to be installed, and (c) whether they have any leads on funding the development and maintenance? Thanks!
1 Like
For your use case @saudiwin is it sufficient to do what brms does? brms uses the Additional_repositories field in the DESCRIPTION file so that CRAN allows it to add CmdStanR as a dependency despite CmdStanR not being on CRAN.
Regarding our plans, I know that CRAN offers several advantages, and I’m glad you’re checking in about this because it’s good for us to think this through from time to time, but I think @Bob_Carpenter summarized the current situation well.
Very true. We definitely need more help on the R side (on all sides really) and it’s been hard to get funding to pay for it, so we rely quite a bit on people who aren’t specifically paid to work on this but can dedicate some of their time to it. We could do a better job recruiting new contributors, but it’s challenging and that takes time too (if anyone has ideas or wants to help out let us know!).
Yeah, we certainly don’t want to break the real functionality of any packages if we can avoid it, but this level of strictness (the particular text of an error or warning message) is very limiting and creates coordination problems when we try to make updates. When we changed the text of the warning messages about divergences (and other diagnostics) in CmdStanR, I was quite glad it wasn’t on CRAN with ~100 reverse dependencies like RStan.
I have indeed been contacted by companies asking about CRAN who don’t seem to have a problem with an unregulated executable or are unaware of that CmdStanR depends on the CmdStan executable. I don’t understand why they would allow an unregulated executable to be installed from GitHub but they wouldn’t allow an R package to be downloaded from GitHub. Thankfully in many of these cases it has ended up being enough to have CmdStanR on R-universe.
1 Like
Thanks so much for the responses, guys, that is super helpful. By “friend” I just meant myself :). My package idealstan uses cmdstanr exclusively, and I can put it on CRAN without having it as a direct dependency (or perhaps with the formulation that Jonah mentioned), but it would be a nice to have.
As far as funding, I see a lot more open source software grants these days and this would seem like a good candidate as it’s a very discrete task. Of course, I have no more time to apply for grants than anyone else. Too bad these companies don’t pony up a bit cough. What might work in the meantime is to fork cmdstanr and then have a version of it that is CRAN-ready and could be maintained by volunteers who manage the burden of getting it on CRAN. That way the current development could go on unimpeded by what CRAN can or can’t do.
And I should say too, this is not a need to have for Bayesian modeling with Stan in R. It’s just something I’m looking into as it would improve the user experience quite a bit than to have the package just tell them to download cmdstanr before they can do anything.
1 Like
Yeah, we have applied for several of these with some (but not enough) success. Unfortunately (for us at least) you’re more likely to get many of these grants if you’re developing something new rather than maintaining a useful existing package, although there are a few grants that do prioritize funding maintenance.
I hadn’t thought about that before. I guess my concern is that the two versions would get out of sync and it would add to the maintenance burden to keep them up to date with each other. If there are really are enough volunteers interested in helping to keep it on CRAN I’d be open to just putting it on CRAN without forking it, but it’s hard to count on volunteers to continue keeping it on CRAN in the future. What often happens is someone will help for a while and then move on to other projects, which is totally fine (and we’re happy to have volunteers like that!), it just makes it hard to plan for future package maintenance.
Makes sense. Although either way they would still need to install CmdStan itself as an extra step.
1 Like
OK I’ll keep this in mind. I think a fork could work because a CRAN version would not need to be updated as frequently (in fact, if it’s a package dependency it would be great to keep it more stable). But it would be a big lift I’m sure, so I’ll just keep this in mind for the future.
Installing cmdstan will always be an extra step, but what is nice is that can be handled from within R with a function (assuming build chain is set up) rather than requiring people to go elsewhere.
Like I said, a nice to have, not a need to have.
1 Like
And were this to ever be accomplished, it’d be necessary to distinguish the packages, so giving a new name to the forked version like “cmdstanrCRAN” or something.
CRANStan, not to be confused with Bryan Cranston (the Breaking Bad actor).
5 Likes