Patrick Schratz
2020-Jun-06 07:04 UTC
[Rd] install.packages(): About an option for installing archived versions
Dear list, Various helpers exist in the wild to install older archived versions of CRAN packages, for example `remotes::install_version() ` or `versions::install.version()`. The former makes use of an ?archive.rds? file stored in the CRAN /Meta directory: https://github.com/r-lib/remotes/blob/9b5dc29102a486df2f42c88bb19027a7cd54a721/R/install-version.R#L68 Given its existence, I was wondering why there is no official support in `install.packages()`? I was browsing the mailing archives of r-devel but surprisingly could not find a previous discussion about it. `remotes::install_version()` only uses the tarballs and enforces installation from source. If it?s due to dependency issues, i.e. that there is no guarantee that older versions work with the current versions of CRAN packages, then the availability of downloading and installing the tarballs manually from the Archive web page could also be questioned per se. I think people know that they are on their own in this situation and that there is no guarantee for archived versions to function properly, especially of one goes back substantially in time. A simple note in ?install.packages() could further clarify this. A few questions: - Does an archive for older binaries exist for CRAN packages? - How is CRAN creating ?archive.rds?? - Would a PR adding this functionality to `install.packages()` be accepted by R-core? Patrick [[alternative HTML version deleted]]
Duncan Murdoch
2020-Jun-06 13:39 UTC
[Rd] install.packages(): About an option for installing archived versions
On 06/06/2020 3:04 a.m., Patrick Schratz wrote:> Dear list, > > Various helpers exist in the wild to install older archived versions of > CRAN packages, for example `remotes::install_version() ` or > `versions::install.version()`. > The former makes use of an ?archive.rds? file stored in the CRAN > /Meta directory: > https://github.com/r-lib/remotes/blob/9b5dc29102a486df2f42c88bb19027a7cd54a721/R/install-version.R#L68 > > Given its existence, I was wondering why there is no official support in > `install.packages()`?Because it's not needed? Some functions belong in base packages because they require access to R internals that aren't available to contributed packages. Other functions support those: base packages can't depend on non-base packages. And finally, some functions are there because some R core member thought they'd be a good idea, and was willing to commit to supporting them. Your suggestion doesn't fit the first two reasons, and I can't see any current R core member wanting to take on extra work unnecessarily. A bit more inline below...> I was browsing the mailing archives of r-devel but surprisingly could > not find a previous discussion about it. > `remotes::install_version()` only uses the tarballs and enforces > installation from source. > If it?s due to dependency issues, i.e. that there is no guarantee that > older versions work with the current versions of CRAN packages, then the > availability of downloading and installing the tarballs manually from > the Archive web page could also be questioned per se. > I think people know that they are on their own in this situation and > that there is no guarantee for archived versions to function properly, > especially of one goes back substantially in time. > A simple note in ?install.packages() could further clarify this. > > A few questions: > > - Does an archive for older binaries exist for CRAN packages?No, nothing like that is maintained. CRAN keeps binaries for the previous version but not indefinitely.> - How is CRAN creating ?archive.rds?? > - Would a PR adding this functionality to `install.packages()` be > accepted by R-core?R isn't maintained on Github so a PR wouldn't make sense, but I also doubt the submission of an svn patch would be acted on unless you come up with some strong arguments about why remotes::install_version doesn't work properly and can't be fixed by its authors. Duncan Murdoch> > Patrick > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >
Patrick Schratz
2020-Jun-06 14:02 UTC
[Rd] install.packages(): About an option for installing archived versions
Duncan, I am not sure if my arguing was understood given your reply. First, I was arguing about the existence of the `archive.rds` metadata file, maintained by CRAN - not the existence of `remotes::install_version()` as a reason for this idea. Second, `install.packages()` is a function accessing both R core and contributed packages, with CRAN being the default repository for the latter. I do not understand the part with the R internals - what does this have to do with installing older versions of both core and contributed packages?> I can't see any current R core member wanting to take on extra work > unnecessarily.What kind of work would be unnecessarily here? The existence of such a function in a contributed package? (Just to understand your point here)> R isn't maintained on Github so a PR wouldn't make sense, but I also > doubt the submission of an svn patch would be acted on unless you come > up with some strong arguments about why remotes::install_version > doesn't work properly and can't be fixed by its authors.I know that R is not maintained on GH. "PR" was just a developer term referring to a "patch" as its called by some. Even though a "patch" sounds more close to "bugfix" than to a general "contribution" meaning. Also again, `remotes::install_version()` is fine. However, in my view, this functionality should be part of `install.packages()` with a simple argument `version`. I am not sure if you mean to argue that due to the existence of contributed packages, no additions to base R need to be made (anymore). Following this thinking, base R packages could be retired since there are alternatives (often more user-friendly and robust ones) for almost every base R function nowadays. The main advantage of base R is its stability and the fact that it comes with the R installation per se. It often does not shine in terms of user-friendliness or type-safetiness. IMO it would be great to have one function for installing packages (i.e. `install.packages()`) that is somewhat flexible, removing the need for multiple contributed functions in other packages to solve this every-day task. Also right now I am feeling a bit more like "sorry for asking" instead of "hey thanks for contributing - this is a valid question and here are our arguments". I am sure many people have had this thought/idea already and weren't self confident enough to ask/discuss this. Thanks for your reply again, appreciated. Maybe the discussion can go on a bit, shining a bit more light on this issue. Patrick On 6 Jun 2020, at 15:39, Duncan Murdoch wrote:> On 06/06/2020 3:04 a.m., Patrick Schratz wrote: >> Dear list, >> >> Various helpers exist in the wild to install older archived versions >> of >> CRAN packages, for example `remotes::install_version() ` or >> `versions::install.version()`. >> The former makes use of an ?archive.rds? file stored in the CRAN >> /Meta directory: >> https://github.com/r-lib/remotes/blob/9b5dc29102a486df2f42c88bb19027a7cd54a721/R/install-version.R#L68 >> >> Given its existence, I was wondering why there is no official support >> in >> `install.packages()`? > > Because it's not needed? Some functions belong in base packages > because they require access to R internals that aren't available to > contributed packages. Other functions support those: base packages > can't depend on non-base packages. And finally, some functions are > there because some R core member thought they'd be a good idea, and > was willing to commit to supporting them. > > Your suggestion doesn't fit the first two reasons, and I can't see any > current R core member wanting to take on extra work unnecessarily. > > A bit more inline below... > > >> I was browsing the mailing archives of r-devel but surprisingly could >> not find a previous discussion about it. >> `remotes::install_version()` only uses the tarballs and enforces >> installation from source. >> If it?s due to dependency issues, i.e. that there is no guarantee >> that >> older versions work with the current versions of CRAN packages, then >> the >> availability of downloading and installing the tarballs manually from >> the Archive web page could also be questioned per se. >> I think people know that they are on their own in this situation and >> that there is no guarantee for archived versions to function >> properly, >> especially of one goes back substantially in time. >> A simple note in ?install.packages() could further clarify this. >> >> A few questions: >> >> - Does an archive for older binaries exist for CRAN packages? > > No, nothing like that is maintained. CRAN keeps binaries for the > previous version but not indefinitely. > >> - How is CRAN creating ?archive.rds?? >> - Would a PR adding this functionality to `install.packages()` be >> accepted by R-core? > > R isn't maintained on Github so a PR wouldn't make sense, but I also > doubt the submission of an svn patch would be acted on unless you come > up with some strong arguments about why remotes::install_version > doesn't work properly and can't be fixed by its authors. > > Duncan Murdoch > >> >> Patrick >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >>[[alternative HTML version deleted]]