> This works for a renamed function. But if the function also changes
> arguments, it doesn't work anymore.
Indeed, didn't think about that. I forgot to mention also that the NOTE appears
only with the old version of the dependency, so it disappears after a couple of
years.
FWIW, CRAN accepts a package with that note.
Georgi
-----Original Message-----
From: Iñaki Ucar <iu...@fedoraproject.org>
Sent: 22 February 2021 10:51
To: Georgi Boshnakov <georgi.boshna...@manchester.ac.uk>
Cc: Duncan Murdoch <murdoch.dun...@gmail.com>; Gábor Csárdi
<csardi.ga...@gmail.com>; R Package Development <r-package-devel@r-project.org>
Subject: Re: [R-pkg-devel] Support for several versions of another package
On Mon, 22 Feb 2021 at 11:46, Georgi Boshnakov
<georgi.boshna...@manchester.ac.uk> wrote:
>
> One way to avoid burying the conditional deep into the code is to put it in
> .onLoad(). When the author of a dependency informed me that from v.2.0.0
> "as.polylist would be renamed I put the following in .onLoad():
>
> .onLoad <- function(libname, pkgname){
> if (utils::packageVersion("PolynomF") >= "2.0.0") {
> assign("as.polylist", PolynomF::as_polylist, envir = topenv())
> }
> ## add other renamed functions here
>
> NULL
> }
>
> This still raises a NOTE but is a change in a single place.
This works for a renamed function. But if the function also changes arguments,
it doesn't work anymore. The only alternative I can think of is to
getFromNamespace() to bypass the check. But it's hackish.
Iñaki
> Georgi Boshnakov
>
>
> -----Original Message-----
> From: R-package-devel <r-package-devel-boun...@r-project.org> On
> Behalf Of Duncan Murdoch
> Sent: 21 February 2021 19:43
> To: Gábor Csárdi <csardi.ga...@gmail.com>
> Cc: R Package Development <r-package-devel@r-project.org>
> Subject: Re: [R-pkg-devel] Support for several versions of another
> package
>
> On 21/02/2021 12:17 p.m., Gábor Csárdi wrote:
> > On Sun, Feb 21, 2021 at 6:05 PM Duncan Murdoch <murdoch.dun...@gmail.com>
> > wrote:
> >>
> >> On 21/02/2021 9:47 a.m., Iñaki Ucar wrote:
> >>> Hi,
> >>>
> >>> Let's say that pkgA uses pkgB::function1. Then, version 2 of pkgB
> >>> removes function1 and exports function2 for the same functionality.
> >>> So pkgA does something along these lines:
> >>>
> >>> if (utils::packageVersion("pkgB") < 2) {
> >>> pkgB::function1()
> >>> } else {
> >>> pkgB::function2()
> >>> }
> >>>
> >>> I'd say that there's nothing wrong with this code, and yet checks
> >>> will complain about "missing o unexported object" in pkgB, for
> >>> either
> >>> function1 or function2 depending on the version of pkgB that is
> >>> available.
> >>>
> >>> Isn't this a false positive? Or is there a better way of doing this?
> >>
> >> I'd agree it's a false positive, but I wouldn't expect the check
> >> code to be able to interpret the logic.
> >>
> >> A better way could be to handle it in your NAMESPACE file. For
> >> example, this is legal (if nonsense):
> >>
> >> if (utils::packageVersion("rgl") < "0.99.0") {
> >> importFrom(rgl, bar = somethingNonexistent) } else
> >> importFrom(rgl, bar = persp3d)
> >
> > Isn't this evaluated at install time? I think it is, and then you
> > would need to potentially reinstall the package when you update rgl,
> > which is not quite ideal, because it is easy to miss it, and then
> > you'll get runtime errors.
>
> Yes, you're right, I didn't know that. That's not as useful.
>
> Duncan Murdoch
>
> ______________________________________________
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> ______________________________________________
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Iñaki Úcar
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
