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@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
