renv VS Prophet

As I alluded to, renv exists, but it requires a lot of development work before it is a comparably robust option for the ecosystem. Basic things like a command-line interface [0], working with non-CRAN repos [1], using an existing DESCRIPTION file [2], etc. There are many use cases where renv does not work in a corporate environment (ie not open-source all public code scenarios). Some of those issues have been open for years.

I do not believe the situation is unsolvable, but there is significant work to be done. Renv provides value today, and I will encourage everyone to use it. However, it has significant blind spots which continue to make R deployments challenging.

[0] https://github.com/rstudio/renv/issues/1055

renv for managing packages in projects.

Oh wow! That is crazy!

I’ve yet to use it personally, but renv [1] seems to try to solve the reproducible builds problem in a way more similar to other modern package managers (e.g. by generating a lockfile).

This approach enables stricter validations against tampering with the package repositories as a hash of the package can be stored in the lockfile, however it is obviously a bit more complex to use than the groundhog approach.

[1]: https://github.com/rstudio/renv

https://facebook.github.io/prophet/

"Prophet is a procedure for forecasting time series data based on an additive model where non-linear trends are fit with yearly, weekly, and daily seasonality, plus holiday effects. It works best with time series that have strong seasonal effects and several seasons of historical data. Prophet is robust to missing data and shifts in the trend, and typically handles outliers well."