# RFC: Return of the Monorepo
**URL:** https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418
**Category:** Developers
**Created:** [June 4, 2018, 8:51am UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418 "2018-06-04T08:51:30Z")
**Posts on this page:** 20
**Page:** 3
### Author:  [@syclik](https://discourse.mc-stan.org/u/syclik)
#### Post date: [June 15, 2018, 6:31pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/46 "2018-06-15T18:31:17Z")
I don’t know if we’ve discussed, but does it make sense to just have the monorepo for stan-dev/stan and stan-dev/math? That way CmdStan, RStan, and PyStan are treated the same.
---
### Author:  [@Bob\_Carpenter](https://discourse.mc-stan.org/u/Bob_Carpenter)
#### Post date: [June 15, 2018, 6:33pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/47 "2018-06-15T18:33:10Z")
Yes, we discussed that.
I’d be more inclined to bring RStan and PyStan into the monorepo at this point. The separate repos have been nothing but a pain for testing with upstream dependencies.
---
### Author:  [@ariddell](https://discourse.mc-stan.org/u/ariddell)
#### Post date: [June 15, 2018, 9:21pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/48 "2018-06-15T21:21:28Z")
With PyStan 3 (httpstan, technically), I’ve stopped using a submodule
for stan and just committed the relevant Stan release tarball into the
tree. It works fine so far.
---
### Author:  [@Bob\_Carpenter](https://discourse.mc-stan.org/u/Bob_Carpenter)
#### Post date: [June 15, 2018, 9:24pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/49 "2018-06-15T21:24:19Z")
How do you keep up with the develop branch of Stan that way?
---
### Author:  [@ariddell](https://discourse.mc-stan.org/u/ariddell)
#### Post date: [June 16, 2018, 12:03pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/50 "2018-06-16T12:03:21Z")
When there’s a new release of Stan that requires changes the relevant
changes are made at the same time as the new Stan code is added to the tree.
---
### Author:  [@wds15](https://discourse.mc-stan.org/u/wds15)
#### Post date: [June 16, 2018, 4:45pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/51 "2018-06-16T16:45:36Z")
The mono repo is great, but I think we should only include the cmdstan interface, because
1. we should have a frontend in order to test all our layers … including the top user-facing interface
2. cmdstan is very light in terms of additional dependencies to have
3. cmdstan is to me the “vanilla” stan - and it’s a good thing to have a reference
However, if we include cmdstan in the mono-repo - how can rstan and pystan make this mono-repo a subbmodule without the cmdstan stuff?
---
### Author:  [@Bob\_Carpenter](https://discourse.mc-stan.org/u/Bob_Carpenter)
#### Post date: [June 17, 2018, 5:30am UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/52 "2018-06-17T05:30:17Z")
> [@ariddell](#):
>
> When there’s a new release of Stan that requires changes the relevant
> changes are made at the same time as the new Stan code is added to the tree.
If that’s only official releases, does that mean you don’t keep up with the develop branch on stan-dev/stan? I guess that’s pretty stable.
> [@wds15](#):
>
> The mono repo is great, but I think we should only include the cmdstan interface
That’s the plan to start. CmdStan is lightweight enough I don’t see a problem bringing that in along with the submodules in R and Python. Sounds like Allen isn’t even using submodules for PyStan.
---
### Author:  [@ariddell](https://discourse.mc-stan.org/u/ariddell)
#### Post date: [June 17, 2018, 12:37pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/53 "2018-06-17T12:37:36Z")
Right, PyStan does not really need to update the Stan source code
between releases. If there is a new Stan feature that requires (early)
testing with development Stan code, I think we’d just do this in a
separate branch.
---
### Author:  [@syclik](https://discourse.mc-stan.org/u/syclik)
#### Post date: [June 19, 2018, 12:23pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/54 "2018-06-19T12:23:01Z")
> [@wds15](#):
>
> The mono repo is great, but I think we should only include the cmdstan interface, because
>
> 1. we should have a frontend in order to test all our layers … including the top user-facing interface
> 2. cmdstan is very light in terms of additional dependencies to have
> 3. cmdstan is to me the “vanilla” stan - and it’s a good thing to have a reference
>
> However, if we include cmdstan in the mono-repo - how can rstan and pystan make this mono-repo a subbmodule without the cmdstan stuff?
Thanks, @wds15. I have similar concerns.
I don’t want to elevate CmdStan above RStan and PyStan (or demote it for that matter). I think they should be on equal footing. I’d rather they were all in or all out. I treat the interfaces that use CmdStan as a different class of interface since they don’t write any C++ code directly.
The only things that could break at the CmdStan level when updating Stan happen rarely:
1. changes to build instructions
2. API changes
The behavior of the samplers are tested at the Stan level and should be kept there.
In my mind, it’s easier if Stan and Math were merged together leaving CmdStan, RStan, and PyStan as separate repos. But I could be convinced that only CmdStan should be there (against what I think is natural) or that all three interfaces live together. It’d be great to have comprehensive tests across the interfaces, but we’ve never gotten that going.
---
### Author:  [@wds15](https://discourse.mc-stan.org/u/wds15)
#### Post date: [June 19, 2018, 12:29pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/55 "2018-06-19T12:29:27Z")
one more point to consider (sorry if already raised) is the reason why we split stan-math apart from stan: As I understood a key advantage of this setup was that the test-burden was much decreased for anything upstream from stan-math.
In practice this means that we do not have to run distributions tests whenever we change things in the language.
Can we still have this convenience with a mono-repo? If the answer is no, then this is a hefty price we are paying here.
---
### Author:  [@seantalts](https://discourse.mc-stan.org/u/seantalts)
#### Post date: [June 19, 2018, 12:37pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/56 "2018-06-19T12:37:14Z")
We will be able to configure testing separately from git history, so we can avoid testing distributions every time we change anything.
I still think that CmdStan:
- is fairly simple, something similar to an “example” or bare bones interface representing the minimal complete Stan implementation
- from a people perspective is grouped with Stan and Math
- is required for end-to-end testing
and so we should include it with the other two repos.
---
### Author:  [@syclik](https://discourse.mc-stan.org/u/syclik)
#### Post date: [June 19, 2018, 12:44pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/57 "2018-06-19T12:44:16Z")
That’s enough of a justification for me to be behind it. I don’t think anyone is trying trying to make CmdStan more than that, so we’re safe for now.
---
### Author:  [@Bob\_Carpenter](https://discourse.mc-stan.org/u/Bob_Carpenter)
#### Post date: [June 19, 2018, 6:09pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/58 "2018-06-19T18:09:08Z")
> [@syclik](#):
>
> I don’t want to elevate CmdStan above RStan and PyStan (or demote it for that matter).
CmdStan is different than RStan and PyStan in many relevant ways:
- BSD license
- pure C++
- zero dependencies outside of those in stan and math libs
- [from @seantalts] same developers as stan and math (for now anyway)
What’s the advantage of not including CmdStan in the monorepo? I like that it gives you an end-to-end functioning package.
> [@wds15](#):
>
> one more point to consider (sorry if already raised) is the reason why we split stan-math apart from stan: As I understood a key advantage of this setup was that the test-burden was much decreased for anything upstream from stan-math.
That was a motivation. But we were wrong. This has hugely increased the test burden now that we do upstream tests which we can’t synchronize.
> [@wds15](#):
>
> In practice this means that we do not have to run distributions tests whenever we change things in the language.
Right, but we do run the other way around, which is much more common.
> [@wds15](#):
>
> Can we still have this convenience with a mono-repo?
Yes, but I think we may just go to more combined testing because it’s too hard to keep all the dependencies in place otherwise.
---
### Author:  [@seantalts](https://discourse.mc-stan.org/u/seantalts)
#### Post date: [October 25, 2018, 5:59pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/59 "2018-10-25T17:59:53Z")
Heads up - I’m working with a contractor who is ready to begin this work. I think it might be a reasonable idea to freeze merges to develop(s) for a week while he finishes? Is that feasible? @Bob_Carpenter
---
### Author:  [@syclik](https://discourse.mc-stan.org/u/syclik)
#### Post date: [October 26, 2018, 3:31pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/60 "2018-10-26T15:31:10Z")
Freezing merges should be ok. I think a week would be fine, but @Bob_Carpenter can reply.
If it doesn’t go as planned, we can always merge into wherever and then reapply the merges afterwards, right? Hopefully we won’t have too many that would need to be reapplied.
---
### Author:  [@seantalts](https://discourse.mc-stan.org/u/seantalts)
#### Post date: [October 26, 2018, 3:43pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/61 "2018-10-26T15:43:15Z")
Yeah, it should be doable and just a few one-offs if we mess up, we’re not super high traffic at the moment.
---
### Author:  [@syclik](https://discourse.mc-stan.org/u/syclik)
#### Post date: [October 26, 2018, 3:53pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/62 "2018-10-26T15:53:14Z")
Cool. And I’m definitely not opposed to a freeze for a week.
---
### Author:  [@mitzimorris](https://discourse.mc-stan.org/u/mitzimorris)
#### Post date: [October 28, 2018, 6:55pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/63 "2018-10-28T18:55:55Z")
found this today:
>
(starting from this: [https://stackoverflow.com/questions/33569189/convert-git-repo-with-submodules-to-single-repo](https://stackoverflow.com/questions/33569189/convert-git-repo-with-submodules-to-single-repo))
---
### Author:  [@Bob\_Carpenter](https://discourse.mc-stan.org/u/Bob_Carpenter)
#### Post date: [October 29, 2018, 5:12pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/64 "2018-10-29T17:12:38Z")
> [@seantalts](#):
>
> Is that feasible? @Bob_Carpenter
Yes, that should be OK. What happens to the PRs in progress now?
---
### Author:  [@Bob\_Carpenter](https://discourse.mc-stan.org/u/Bob_Carpenter)
#### Post date: [October 29, 2018, 5:13pm UTC](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418/65 "2018-10-29T17:13:17Z")
> [@mitzimorris](#):
>
> found this today:
Thanks—that looks like the kind of thing we need.
[Previous page](https://discourse.mc-stan.org/t/rfc-return-of-the-monorepo/4418.md?page=2)