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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Patrick Johann Schratz
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]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: install.packages(): About an option for installing archived versions

Duncan Murdoch-2
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]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: install.packages(): About an option for installing archived versions

Patrick Johann 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]]
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel