R devel - Jun 2020 - 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]]

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
>

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]]