[R-pkg-devel] Support for several versions of another package
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?
Regards,
--
Iñaki Úcar
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Support for several versions of another package
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)
Now in the package you can refer to bar, and it'll be persp3d for a new
version of rgl, somethingNonexistent for an old one. You won't get a
warning that somethingNonexistent doesn't exist as long as you're not on
the old version of rgl.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Support for several versions of another package
On Sun, Feb 21, 2021 at 6:05 PM Duncan Murdoch 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.
Gabor
> Now in the package you can refer to bar, and it'll be persp3d for a new
> version of rgl, somethingNonexistent for an old one. You won't get a
> warning that somethingNonexistent doesn't exist as long as you're not on
> the old version of rgl.
>
> 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
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 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-pkg-devel] Two compile questions
Hi, I'm in the process of incorporating some improvements that I pulled from github. I am getting a warning and a note. These occur when I run R CMD check --as-cran fftwtools_0.9-10.tar.gz 1. * checking whether package ‘fftwtools’ can be installed ... WARNING Found the following significant warnings: 'config' variable 'CPP' is deprecated See ‘/home/karim/PWLisp/fftwtools.Rcheck/00install.out’ for details. In the .out file I have the following: * installing *source* package ‘fftwtools’ ... ** using staged installation 'config' variable 'CPP' is deprecated checking for gcc... gcc -std=gnu99 2. Package has both ‘src/Makevars.in’ and ‘src/Makevars’. Installation with --no-configure' is unlikely to work. If you intended ‘src/Makevars’ to be used on Windows, rename it to ‘src/Makevars.win’ otherwise remove it. If ‘configure’ created ‘src/Makevars’, you need a ‘cleanup’ script. I cannot find a Makevars file. I do have a Makevars.win file. I would appreciate any help. R version 4.0.4 (2021-02-15) -- "Lost Library Book" Copyright (C) 2021 The R Foundation for Statistical Computing Platform: x86_64-pc-linux-gnu (64-bit) Thanks, Karim [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
