RFC: Return of the Monorepo


#41

Stan’s tied to the BH package in R. We use whichever version of Boost they’re up to. They’ve been good about adding extra components, but I think we’re on our own with the non header-only ones we’re using for MPI.

What we’ve done in the past is put our own version of a boost header file on the include path ahead of theirs so our header guard prevents theirs from being read. That lets us do things like remove the pesky error messages. I don’t think we’ve been doing that recently, though.

Are there specific problems in the std libs we need to address?


#42

For problems in std libs, it is just stuff I ran into while writing the complex math stuff for libc++ vs libstdc++. All of that is solved now and I am just rewriting to make everything fit stan’s existing structure, so no problems from me.


#43

It’s particularly painful around the places where C99 added something but C++03 did not—the namespaces vary a lot with respect to which includes you use and whether things go into the top-level :: or std:: namespaces.


#44

rstan is still doing it, but it has only been 9 commits in four years. Not a big deal, but hopefully can be shrunk when C++11 is turned on.


#45

Okay, I think this deserves to be a separate thread and not tied to the monorepo proposal or implementation. Happy to let whoever feels strongly about this make the case there and propose their own plan for switching to git submodules for Boost or whatever other libraries people care about becoming submodules.


#46

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.


#47

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.


#48

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.


#49

How do you keep up with the develop branch of Stan that way?


#50

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.


#51

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?


#52

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.

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.


#53

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.