I am a C programmer. I have always been a C programmer. I have been thrown neck deep into someone else’s npm project with directions written for npm programmers and I am drowning under angry command line output like “figgy pudding is deprecated”
@0xabad1dea Given the choice, I'd pick C over Javascript too. C makes me itchy (not being a CS or EE person) but I can deal with it. I still have bad memories of Javascript from 1998 and the modern incarnation does not fill me with faith or joy.
I'm qualifying an R application and I need to formally document all the dependencies and their versions. I'm not sure how regulators will react when they see 'R 3.4.3 "Kite-Eating Tree"' https://www.r-statistics.com/2017/12/r-3-4-3-is-released-a-bug-fix-release/
@arclight @0xabad1dea
Do note that R doesn't really version its dependencies; whatever code your software runs today isn't necessarily what it runs tomorrow.
And more importantly, any given version of R doesn't keep its packages. Installing the exact same version of R in a year will likely be largely broken.
@jannem @arclight That's where packages like {renv} can help. You record the packages you are using and their versions. and you can reinstall exactly these versions into a project specific library. See https://rstudio.github.io/renv/ for more details.
@rstub @jannem We retain source archives of all dependencies; the code is built and operated in an environment with limited/no internet connectivity. We're looking at {renv} but this really needs to be pushed upstream to the code's vendor. It would be much simpler if this application was implemented as a statically-compiled binary but that is unlikely given the code's origin. Interpreted research-oriented code does not deal well with strict configuration management; it's a generic problem with popular dynamic/interpreted languages.