Also, it appears that Groundhog is itself a CRAN package and the author recommends installing with install.packages(). So is the author committing to never making any backwards incompatible updates to their new package?
Also, because groundhog isn't made for the author to use, whether or not the interface changes is irrelevant. You'll never encounter library(groundhog) in a paper.
It reconstructs how the fully updated version of everything worked that day which isn't necessarily the same as the researcher's environment. It's a horrible idea to use dates instead of package versions for this. The author's library doesn't solve the problem it claims to solve.
Well, yes, probably. It's not all that hard, and groundhog seems to have a fairly simple API anyways.
And groundhog still uses CRAN packages, it just brings a method of pinning them to a specific version.
How else would you install the cran packages without using install.packages? Unless if you want them to recursively install it using groundhog but that seems unnecessary.
As long as you have the timestamp it should work, though I assume there will be some edge case.
What you're saying is like don't use pip because you don't install it using pip? Or don't use package-lock.json because you can't install npm through npm?
OP is not claiming that Groundhog itself is a threat to the R language ecosystem itself, whereas the author is claiming that the R language is itself a threat to Science itself...