I’m wondering if it might be prudent to backport any simple fixes to 2.19 (i.e., make a hotfix release). There were some fixes to some of the math functions, right?
Here’s my reasoning. It’s going to take several months before PyStan figures out a way to build non-header-only reliably. So lots of people are going to continue to use the 2.19 version of Stan.
Moreover, it might be many more months before we figure out a way to build on Windows specifically. (Figuring out a way to build Stan non-header-only on Linux is a different task than doing the same thing on Windows.)
Given that the entire Stan math file system structure has bee changed, any backports are going to be a major pain. On top our meta programs keep improving…which means they change. I don’t quite see that we have the resources to do lots of backporting. Only really serious stuff.
What about cmdstanpy for the moment being? Isn’t that a good option for python users?
If there are no serious bugs (e.g., fixes to distribution functions) then we likely don’t need to worry about this. I imagined very limited backporting, if any.
What if pystan just used current stan math but without the TBB, until you find a solution for linking?
I see. Well, that’s a question to our folks managing the release (@serban-nicusor ?)
This would not work with the current math as is. I can provide a small patch to Stan-math which will make the TBB optional whenever STAN_THREADS is not in use - RStan needed this as well. Making the TBB fully optional would require some work to be done for Stan math … which is probably better spend on making PyStan work with a non-header only Stan-math version (like exploring swig).
I don’t want to confuse people. We have a solution for linking on Linux and macOS – and we think it will work on Windows. It’s just going to take time to get everything working. The solution involves a lot of changes to our build system.