[Rd] install.packages(): About an option for installing archived versions

[Patrick Schratz]

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 using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>

	[[alternative HTML version deleted]]