# Stan R package repository

**URL:** <https://discourse.mc-stan.org/t/stan-r-package-repository/15749>\
**Category:** Developers\
**Tags:** r\
**Created:** [June 8, 2020, 9:10am UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749 "2020-06-08T09:10:08Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![rok\_cesnovar](https://avatars.discourse-cdn.com/v4/letter/r/7bcc69/32.png) [@rok\_cesnovar](https://discourse.mc-stan.org/u/rok_cesnovar)\
**Post date:** [June 8, 2020, 9:10am UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/1 "2020-06-08T09:10:08Z")

</div>

Is there any interest among the stan-dev R package developers for making a independent package repository for the official stan-dev R packages?

I am not proposing this with eliminating CRAN in mind, but as an easier way of publishing new R package versions before they reach CRAN or for R packages that have no interest in getting on CRAN.

This is a much simpler alternative to using `devtools::install_github()`, allows distributing binary packages and also allows CRAN-hosted packages to use these packages [even if not on CRAN](https://stackoverflow.com/questions/33335321/include-non-cran-package-in-cran-package).

The users would add our repository to their list of repositories:

```
options(repos = c("https://packages.mc-stan.org", getOption("repos"))

```

and then `install.packages("cmdstanr")` or `install.packages("rstan")` would install the newest version available on our repository. The alternative would be to specify our repository only for specific stuff.

```
install.packages("cmdstanr", repos = c("https://packages.mc-stan.org"))

```

There are two ways we could go about doing this:

- use a Github repository as a package repository

Any Github repository can be a static website. Hence any Github repository can also be used for hosting R packages. Example: [https://github.com/RcppCore/drat](https://github.com/RcppCore/drat)  
In this case

```
install.packages("Rcpp", repos="https://RcppCore.github.io/drat")

```

would install from this repository. The downside of this is that Github was never really meant for hosting huge tarball files, so this is probably only useful for a small number of packages with not a lot of turnaround. Which might be our case, I dont know.

- self hosted static web page

In this case we need to have a static web page (for example [http://packages.mc-stan.org](http://packages.mc-stan.org)) hosted somewhere. Maybe we could add that to the same machine that hosts [https://jenkins.mc-stan.org/](https://jenkins.mc-stan.org/) and add the packages sub-domain to it but I am not sure how busy the machine is right now and if it could handle the additional load. @serban-nicusor how busy is the machine running [https://jenkins.mc-stan.org/](https://jenkins.mc-stan.org/)?

- static web page hosted on AWS S3 or some other hosting provider

This obviously brings some additional costs, I am not exactly sure how much though, as its hard to estimate all the different traffic numbers you need to input in the hosting pricing calculator to get a ballpark number for monthly pricing. I think @ahartikainen mentioned once that azure and NumFocus have some kind of agreement for open-source projects and free services. I am not sure if that is still relevant.

Huge thanks to @dpastoor for the initial information on this in the [cmdstanr thread](https://github.com/stan-dev/cmdstanr/issues/168#issuecomment-630361841).

@dpastoor would you maybe know a ballpark figure of the ROpenSci AWS S3 traffic numbers or charge? Ours would obivously smaller than rOpenSCI.

cc: @jonah @bgoodri @paul.buerkner

---

<div class="post-metadata">

**Author:** ![serban-nicusor](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/serban-nicusor/32/5182_2.png) [@serban-nicusor](https://discourse.mc-stan.org/u/serban-nicusor)\
**Post date:** [June 8, 2020, 9:26am UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/2 "2020-06-08T09:26:18Z")

</div>

Hey @rok_cesnovar I think we have enough resources on the Jenkins machine to host a static web page if that’s just for getting packages from time to time and not a continuous usage of resources. LInk me if you find a good web-ui package manager or if we need ours and I can put it up!

---

<div class="post-metadata">

**Author:** ![rok\_cesnovar](https://avatars.discourse-cdn.com/v4/letter/r/7bcc69/32.png) [@rok\_cesnovar](https://discourse.mc-stan.org/u/rok_cesnovar)\
**Post date:** [June 8, 2020, 9:37am UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/3 "2020-06-08T09:37:13Z")

</div>

So for example, rOpenSci has [http://packages.ropensci.org/](http://packages.ropensci.org/) which is just a Jenkins landing page. But the UI does not really matter as it would be used inside R not from the browser. The main thing is that src/contrib returns a list of packages, that src/contrib/PACKAGES returns a file and that we have tar.gz files in src/contrib.

Example:

- [http://packages.ropensci.org/src/contrib](http://packages.ropensci.org/src/contrib) this would be re-generated on update of packages but would be a static page
- [http://packages.ropensci.org/src/contrib/PACKAGES](http://packages.ropensci.org/src/contrib/PACKAGES) - same as above
- [http://packages.ropensci.org/src/contrib/pdftools\_2.3.1.9000.tar.gz](http://packages.ropensci.org/src/contrib/pdftools_2.3.1.9000.tar.gz) - an example of a package

Rstan source package is 1 MB, its MacOS binary is ~20MB and its Windows binary I think ~5MB. And that package is probably among the largest we would host (rstanarm is a bit bigger but this is the general ballpark for largest packages) .

RStan has 85K downloads per month on CRAN, this would definitely much less than that. Would it handle lets says 1k per month or 10k?

---

<div class="post-metadata">

**Author:** ![paul.buerkner](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/paul.buerkner/32/3303_2.png) [@paul.buerkner](https://discourse.mc-stan.org/u/paul.buerkner)\
**Post date:** [June 8, 2020, 10:09am UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/4 "2020-06-08T10:09:01Z")

</div>

Just wanted to comment that I am very much in favor of this proposal, especially to already use cmdstanr and posterior in our other CRAN hosted packages.

---

<div class="post-metadata">

**Author:** ![ahartikainen](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/ahartikainen/32/321_2.png) [@ahartikainen](https://discourse.mc-stan.org/u/ahartikainen)\
**Post date:** [June 8, 2020, 10:43am UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/5 "2020-06-08T10:43:45Z")

</div>

> [@rok\_cesnovar](#):
>
> I think @ahartikainen mentioned once that azure and NumFocus have some kind of agreement for open-source projects and free services. I am not sure if that is still relevant.

At least for Azure DevOps (similar to Github Actions), but I don’t know if they have Azure credits too, probably.

---

<div class="post-metadata">

**Author:** ![rok\_cesnovar](https://avatars.discourse-cdn.com/v4/letter/r/7bcc69/32.png) [@rok\_cesnovar](https://discourse.mc-stan.org/u/rok_cesnovar)\
**Post date:** [June 8, 2020, 12:18pm UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/6 "2020-06-08T12:18:07Z")

</div>

So the main question is probably which of the stan-dev R packages would want to use this. We will use some variation of this for cmdstanr and posterior. If those will be the only two, I think making a Github repository will suffice (with [packages.mc-stan.org](http://packages.mc-stan.org) redirecting there). But if other R packages would want to use this as well it would make more sense to host this somewhere else.

---

<div class="post-metadata">

**Author:** ![jonah](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/jonah/32/200_2.png) [@jonah](https://discourse.mc-stan.org/u/jonah)\
**Post date:** [June 8, 2020, 4:46pm UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/7 "2020-06-08T16:46:07Z")

</div>

> [@paul.buerkner](#):
>
> Just wanted to comment that I am very much in favor of this proposal, especially to already use cmdstanr and posterior in our other CRAN hosted packages.

Me too!

> [@rok\_cesnovar](#):
>
> So the main question is probably which of the stan-dev R packages would want to use this. We will use some variation of this for cmdstanr and posterior.

I’m not sure if there’s a need for this for packages like bayesplot, shinystan, loo, projpred (although I’m not opposed to it for those packages and maybe there are compelling reasons), but I definitely think this could be useful for rstanarm. We often have fixes/changes to rstanarm that are difficult for people to use until they make it into a CRAN release because `install_github()` is a pain with rstanarm (it has to compile all the models). But we don’t do too many CRAN releases of rstanarm, so it would be nice to be able to offer some binaries that can be easily installed when people are waiting for bugfixes or new features that aren’t on CRAN. @bgoodri what do you think (for rstanarm and rstan)?

---

<div class="post-metadata">

**Author:** ![jonah](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/jonah/32/200_2.png) [@jonah](https://discourse.mc-stan.org/u/jonah)\
**Post date:** [June 9, 2020, 7:11pm UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/8 "2020-06-09T19:11:22Z")

</div>

We (really 99% Rok) have started this at [https://github.com/stan-dev/r-packages](https://github.com/stan-dev/r-packages). So far it has the latest `cmdstanr` and `posterior`. For example, this now works:

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

```

---

<div class="post-metadata">

**Author:** ![wds15](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wds15/32/908_2.png) [@wds15](https://discourse.mc-stan.org/u/wds15)\
**Post date:** [June 10, 2020, 7:18am UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/9 "2020-06-10T07:18:47Z")

</div>

I really hope this repository now does not mean we start to dump CRAN.

We do have a policy in place that only things from CRAN can be installed into our production R easily. I could imagine that other companies have similar things in place which would not at all play nice with such a develop repository.

The long rstan version lockdown is about to be resolved… hopefully sustainably.

---

<div class="post-metadata">

**Author:** ![rok\_cesnovar](https://avatars.discourse-cdn.com/v4/letter/r/7bcc69/32.png) [@rok\_cesnovar](https://discourse.mc-stan.org/u/rok_cesnovar)\
**Post date:** [June 10, 2020, 7:42am UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/10 "2020-06-10T07:42:09Z")

</div>

> [@wds15](#):
>
> I really hope this repository now does not mean we start to dump CRAN.

No, this is only meant so that we can publish binaries for new features/bugfixes ahead of time. And that CRAN packages like brms can use posterior/cmdstanr before those reach CRAN.

Or for example a lot users want to use feature/survival branch of rstanarm which is not on CRAN. We could build those binaries for Mac/Win and host them here.

> [@wds15](#):
>
> The long rstan version lockdown is about to be resolved…

Careful there, dont jinx Ben :)

---

<div class="post-metadata">

**Author:** ![wds15](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wds15/32/908_2.png) [@wds15](https://discourse.mc-stan.org/u/wds15)\
**Post date:** [June 10, 2020, 8:03am UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/11 "2020-06-10T08:03:16Z")

</div>

> [@rok\_cesnovar](#):
>
> And that CRAN packages like brms can use posterior/cmdstanr before those reach CRAN.

I would be careful here. At the moment when brms uses posterior/cmdstanr, then brms won’t be able to be put on CRAN as well. Or did I miss something here?

> [@rok\_cesnovar](#):
>
> Or for example a lot users want to use feature/survival branch of rstanarm which is not on CRAN. We could build those binaries for Mac/Win and host them here.

Sure… but it’s still a pity that this functionality is not on CRAN which is the real solution here. My concern is that this repository is encouraging to move away from CRAN. If this is more a dev only thing… fine, but for that I would have thought that Docker is better (but I did not yet have time to seriously work that out nor is it a given that devs are fluent with Docker… sure).

> [@rok\_cesnovar](#):
>
> Careful there, dont jinx Ben :)

I did put a lot of work into getting this resolved (OK, Ben probably a lot more), but I am optimistic here.

So I hope the common sense is still that things are headed to CRAN wrt to R (but it’s not me to make these decisions, of course).

---

<div class="post-metadata">

**Author:** ![rok\_cesnovar](https://avatars.discourse-cdn.com/v4/letter/r/7bcc69/32.png) [@rok\_cesnovar](https://discourse.mc-stan.org/u/rok_cesnovar)\
**Post date:** [June 10, 2020, 10:40am UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/12 "2020-06-10T10:40:46Z")

</div>

I was fearing this would turn in to a CRAN vs. anti-CRAN. So lets not go there, please. No one is suggesting we ditch CRAN. I am aware of the safety-related procedures that prevent the use of non-CRAN stuff.

> [@wds15](#):
>
> I would be careful here. At the moment when brms uses posterior/cmdstanr, then brms won’t be able to be put on CRAN as well. Or did I miss something here?

CRAN packages can have the Additional\_repositories field to include non-CRAN packages if they are strictly optional. So if cmdstanr is an optional backend that would work. See [Host cmdstanr on 'drat' for use in CRAN packages before release · Issue #168 · stan-dev/cmdstanr · GitHub](https://github.com/stan-dev/cmdstanr/issues/168) and the links there.

> [@wds15](#):
>
> Sure… but it’s still a pity that this functionality is not on CRAN which is the real solution here.

Yes, but there are probably good reasons why its not on CRAN right now? I am guessing, I dont know. I read something about RAM usage, but dont know the details. And since rstanarm and install\_github dont work well for non-power users, this is a really really simple solution for:

- publishing fixes before they reach CRAN

Stan R packages structure makes publishing on CRAN a slow process and users want to try out new things and start to build from source which leads to a bunch of support questions that could be avoided.

- publishing packages that will never be able to be published on CRAN due to some CRAN-limitation
- publishing packages in alpha/beta/pre-CRAN stage (see posterior, cmdstanr)

> [@wds15](#):
>
> My concern is that this repository is encouraging to move away from CRAN.

Not sure why you feel that way. The first line on the repo says: “A place for publishing new versions of (some) stan-dev R packages before they reach CRAN and for stan-dev R packages and versions where releasing on CRAN is not a (current) goal.”

I would actually argue that by adding this repository, we could get more things or CRAN faster, rather than less, as it could lead to less support questions.

> [@wds15](#):
>
> but I am optimistic here.

I really hope it gets through! Getting stanc3 in Rstan would be huge.

---

<div class="post-metadata">

**Author:** ![Bob\_Carpenter](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/bob_carpenter/32/9230_2.png) [@Bob\_Carpenter](https://discourse.mc-stan.org/u/Bob_Carpenter)\
**Post date:** [June 29, 2020, 9:32pm UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/13 "2020-06-29T21:32:32Z")

</div>

> [@wds15](#):
>
> We do have a policy in place that only things from CRAN can be installed into our production R easily.

There’s always Python :-)

> [@rok\_cesnovar](#):
>
> I would actually argue that by adding this repository, we could get more things or CRAN faster,

It sounds to me like the plan is to have packages like BRMS depend on non-CRAN packages like CmdStanR. Does that work for @wds15?

---

<div class="post-metadata">

**Author:** ![jonah](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/jonah/32/200_2.png) [@jonah](https://discourse.mc-stan.org/u/jonah)\
**Post date:** [June 29, 2020, 10:37pm UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/14 "2020-06-29T22:37:45Z")

</div>

> [@Bob\_Carpenter](#):
>
> It sounds to me like the plan is to have packages like BRMS depend on non-CRAN packages like CmdStanR. Does that work for @wds15?

That shouldn’t affect anything for @wds15. We won’t add a dependency on a non-CRAN package unless that dependency is a “soft” dependency (i.e., not actually required but can be used if present).

Also, we should be able to get CmdStanR onto CRAN eventually. (But don’t worry: it won’t have the issues RStan has on CRAN since CmdStanR doesn’t use StanHeaders and we’re not distributing CmdStan with CmdStanR. The only thing that would go onto CRAN is the CmdStanR R code.)

---

<div class="post-metadata">

**Author:** ![wds15](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/wds15/32/908_2.png) [@wds15](https://discourse.mc-stan.org/u/wds15)\
**Post date:** [June 30, 2020, 10:47am UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/15 "2020-06-30T10:47:45Z")

</div>

> [@jonah](#):
>
> That shouldn’t affect anything for @wds15. We won’t add a dependency on a non-CRAN package unless that dependency is a “soft” dependency (i.e., not actually required but can be used if present).

+1 on that!

> [@jonah](#):
>
> Also, we should be able to get CmdStanR onto CRAN eventually. (But don’t worry: it won’t have the issues RStan has on CRAN since CmdStanR doesn’t use StanHeaders and we’re not distributing CmdStan with CmdStanR. The only thing that would go onto CRAN is the CmdStanR R code.)

There are a ton of features now in cmdstan which make it really urgent from my view to get cmdstanR on CRAN, but I am not able to judge on its readiness (but on its need).

---

<div class="post-metadata">

**Author:** ![jonah](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/jonah/32/200_2.png) [@jonah](https://discourse.mc-stan.org/u/jonah)\
**Post date:** [June 30, 2020, 6:13pm UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/16 "2020-06-30T18:13:46Z")

</div>

> [@wds15](#):
>
> There are a ton of features now in cmdstan which make it really urgent from my view to get cmdstanR on CRAN, but I am not able to judge on its readiness (but on its need).

Yeah I agree. Not quite ready yet, but almost!

---

<div class="post-metadata">

**Author:** ![Bob\_Carpenter](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/bob_carpenter/32/9230_2.png) [@Bob\_Carpenter](https://discourse.mc-stan.org/u/Bob_Carpenter)\
**Post date:** [July 6, 2020, 9:09pm UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/17 "2020-07-06T21:09:54Z")

</div>

> [@jonah](#):
>
> We won’t add a dependency on a non-CRAN package unless that dependency is a “soft” dependency (i.e., not actually required but can be used if present).

But isn’t CmdStan that soft dependency? I have a hard time believing that it’d be OK to a security-minded sysadmin would require R software to come from CRAN, then open the backdoor to download , compile, and execute arbitrary C++ code.

So I’m very surprised by the reply:

> [@wds15](#):
>
> +1 on that!

If I had a nickel for every time I guessed wrong about a large company’s behavior, I’d have enough money to buy dinner.

---

<div class="post-metadata">

**Author:** ![jonah](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/jonah/32/200_2.png) [@jonah](https://discourse.mc-stan.org/u/jonah)\
**Post date:** [July 7, 2020, 11:38pm UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/18 "2020-07-07T23:38:10Z")

</div>

Maybe I’m misunderstanding, but I don’t see the problem. brms, for example, wouldn’t offer a function to install cmdstan. If cmdstanr and cmdstan happen to be installed it will just be capable of using them. So if Novartis doesn’t want to allow cmdstanr then they will have no risk of cmdstan being used even if they allow a package like brms that is capable of using it.

---

<div class="post-metadata">

**Author:** ![Bob\_Carpenter](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/bob_carpenter/32/9230_2.png) [@Bob\_Carpenter](https://discourse.mc-stan.org/u/Bob_Carpenter)\
**Post date:** [July 8, 2020, 8:04pm UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/19 "2020-07-08T20:04:40Z")

</div>

> [@jonah](#):
>
> brms, for example, wouldn’t offer a function to install cmdstan.

Won’t that make things challenging for brms users?

Will brms depend on cmdstanr? If so, does that mean as soon as brms is installed, the cmdstan installer that’s part of cmdstanr will also be included?

My guess is that users with security-conscious IT departments will need to get approval for both cmdstanr and cmdstan. Just approving CRAN shouldn’t be good enough to get a working cmdstanr because it depends on a foreign executable.

---

<div class="post-metadata">

**Author:** ![jonah](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.mc-stan.org/jonah/32/200_2.png) [@jonah](https://discourse.mc-stan.org/u/jonah)\
**Post date:** [July 8, 2020, 10:45pm UTC](https://discourse.mc-stan.org/t/stan-r-package-repository/15749/20 "2020-07-08T22:45:20Z")

</div>

> [@Bob\_Carpenter](#):
>
> Will brms depend on cmdstanr? If so, does that mean as soon as brms is installed, the cmdstan installer that’s part of cmdstanr will also be included?

No, that’s what I’ve been trying to say ;) It will only depend on rstan. cmdstanr is not required. perhaps it was my initial use of “soft dependency” that was the problem. brms will not depend on cmdstanr or cmdstan. It would be available as an optional add-on, but Novartis can just not whitelist cmdstanr and there’s no problem.

[Next page](https://discourse.mc-stan.org/t/stan-r-package-repository/15749.md?page=2)