3 ms·

This title is an exceedingly hot take for someone who wrote a new package manager. Also, it appears that Groundhog is itself a CRAN package and the author reco

This title is an exceedingly hot take for someone who wrote a new package manager. 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?

resonantjacket5 6y ago
Your take seems a bit 'hot' too? 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?
- cat199 6y ago
  > Your take seems a bit 'hot' too? 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...
- scottmcdot 6y ago
  Someone correct me if I'm wrong, but can't you copy and paste the package folder into your libpath directory and R can load it that way with actually running install.packages()?
  - vharuck 6y ago
    Usually, yes. However, it is possible for a package to have code that only runs when it is installed. If you just copy-paste, it won't be run.
- cauthon 6y ago
  No, I’m saying don’t call CRAN a “threat to reproducible science” and then make your solution a CRAN package
coolreader18 6y ago
> So is the author committing to never making any backwards incompatible updates to their new package? 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.
bsza 6y ago
I think it's more like a Wayback Machine for R programs, since the author of a science paper isn't required to use groundhog. You can just provide it the date the article was published, which you already know, and it reconstructs how the program worked on that day. 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.
- st1x7 6y ago
  > and it reconstructs how the program worked on that day. 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.
  - SCLeo 6y ago
    If I am understanding this correctly, the problem is that the paper authors do not provide a specific version or a package.json equivalent. In that case, using dates seem to be the only choice.
    - st1x7 6y ago
      Even if that's the case, using dates isn't a solution because dates don't give you the build that the researcher used. Date of publication is different from the date when the code ran and there is no guarantee that the researcher ran the latest version of every dependency that was available to them anyway. In fact that's very unlikely considering that some their libraries might require older versions. It might not even be possible to take the latest version of every package and use them in the same environment.
      - SCLeo 6y ago
        So, what is your better alternative then? I honestly believe using version available at that date is better than using the latest version.
jsmith99 6y ago
That's the problem. This package is very similar to Microsoft's checkpoint package which is based on Microsoft's MRAN snapshots, and this package also uses MRAN. The article explains the difference is that this package allows you to specify the date in the code itself, whereas checkpoint is used to set a whole installation to a specific date. But this is no advantage as it means code will stop working if the groundhog package changes, whereas with checkpoint a paper could just say 'use packages as of date x'.

resonantjacket5 6y ago

Your take seems a bit 'hot' too? 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?

cat199 6y ago
> Your take seems a bit 'hot' too? 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...
scottmcdot 6y ago
Someone correct me if I'm wrong, but can't you copy and paste the package folder into your libpath directory and R can load it that way with actually running install.packages()?
- vharuck 6y ago
  Usually, yes. However, it is possible for a package to have code that only runs when it is installed. If you just copy-paste, it won't be run.
cauthon 6y ago
No, I’m saying don’t call CRAN a “threat to reproducible science” and then make your solution a CRAN package

coolreader18 6y ago

> So is the author committing to never making any backwards incompatible updates to their new package? 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.

bsza 6y ago

I think it's more like a Wayback Machine for R programs, since the author of a science paper isn't required to use groundhog. You can just provide it the date the article was published, which you already know, and it reconstructs how the program worked on that day. 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.

st1x7 6y ago
> and it reconstructs how the program worked on that day. 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.
- SCLeo 6y ago
  If I am understanding this correctly, the problem is that the paper authors do not provide a specific version or a package.json equivalent. In that case, using dates seem to be the only choice.
  - st1x7 6y ago
    Even if that's the case, using dates isn't a solution because dates don't give you the build that the researcher used. Date of publication is different from the date when the code ran and there is no guarantee that the researcher ran the latest version of every dependency that was available to them anyway. In fact that's very unlikely considering that some their libraries might require older versions. It might not even be possible to take the latest version of every package and use them in the same environment.
    - SCLeo 6y ago
      So, what is your better alternative then? I honestly believe using version available at that date is better than using the latest version.

jsmith99 6y ago

That's the problem. This package is very similar to Microsoft's checkpoint package which is based on Microsoft's MRAN snapshots, and this package also uses MRAN. The article explains the difference is that this package allows you to specify the date in the code itself, whereas checkpoint is used to set a whole installation to a specific date. But this is no advantage as it means code will stop working if the groundhog package changes, whereas with checkpoint a paper could just say 'use packages as of date x'.