I have been experimenting with Pyro, coming from Stan and Pymc3 and I quite like it. I have introduced my coworkers to it, but many of them lack expertise in probabilistic programming and while they do get the main ideas of priors and posteriors, they aren’t familiar enough with many of the concepts to easily digest frameworks like pyro. So, some of them have asked me if I could write a wrapper for some of the more common models we use, like linear regression and basic time series.
I would like to do this, but I am not sure how stable the Pyro API and inference tools are since everything is still in beta. I guess I would like to know if there are any plans to make serious changes to Pyro as it heads towards its official release, or if the current version is stable enough to write a wrapper around the API and have it not break in the near future (or give bad results with simple models)
tl;dr Pyro is at least as stable as PyTorch. Consider adding to pyro.contrib.
We don’t foresee major language changes in the 1-year time span, and historically PyTorch has made more breaking changes than Pyro between minor releases. In general we value all the great documentation and tutorial material out there, and we’ve tried to avoid change so as to keep all of that material relevant. Most of our current effort is in building alternate backends that aim to be compatible with the Pyro language (e.g. JAX, Funsor, maybe Birch).
We’ve also confirmed your observation that many users prefer simple wrappers rather than needing to write their own models (especially subtle bugs in convergence and silent errors due to tensor dimension mismatch). We’d be happy to review and maintain pyro.contrib modules in case you’d like to implement any of your wrappers there. On advantage of keeping some of your code in pyro.contrib is that its tests will be run on every Pyro commit.
I believe Paul Horsfall is working on a linear regression wrapper around Pyro, and we have vague intentions to build a time series wrapper. If you have designs for either of these two wrappers, we’d be happy to collaborate in pyro.contrib.
We just released Pyro 1.0 and clarified stability. There have been some minor breaking changes between when you wrote this and the 1.0 release, but hereafter we plan on backwards compatibility. Like you, my team is building high level components on top of Pyro (e.g. BRMP and pyro.contrib.timeseries). We are also stabilizing the pyro api to enable these high-level components to use alternative backends such as NumPyro (e.g. BRMP can use either the standard Pyro backend or the NumPyro backend).
Thanks for your original question, your nudge helped us get to a 1.0 release
For what it’s worth, I’ve been using Pyro at a pretty big SaaS (software as a service) company. The models built using Pyro serve a few hundred thousand predictions daily. My experience with Pyro and its stability have been really positive.
With the 1.0 release, I plan to update the models to use pyro.infer.Predictive. That being said, there’s no big rush to do this - I’ll just do it as part of normal iterations.
