Perfect. You also mention the “backports” package - how can I use that one to
be able to also support old versions of R?
Thanks,
Rainer
> On 23 Jun 2020, at 16:34, Hong Ooi wrote:
>
> Yes, that’s the one.
>
> From: Rainer M Krug
> Sent: Tuesday, 23 June 2020 11:12 PM
> To: Hong Ooi
> C
Yes, but I think my concern may have been bogus. WRE says that even though
the whole package is loaded, it is *not* placed on the search path. Only
exports from the package go on the search path. So if the imported generic
is not then explicitly exported, it would not be seen nor cause a conflict
w
On 23/06/2020 10:28 a.m., Viechtbauer, Wolfgang (SP) wrote:
Still, if pkgA imports the generic from pkgB, then installing pkgA installs
pkgB and all of its dependencies (Depends and Imports). Which of course makes
sense (as otherwise pkgB cannot be installed). But all of this just for
importin
Yes, that’s the one.
From: Rainer M Krug
Sent: Tuesday, 23 June 2020 11:12 PM
To: Hong Ooi
Cc: R Package Devel
Subject: Re: [EXTERNAL] [R-pkg-devel] Proper CRAN way - How to handle
dependency of java jar file?
Thanks Hong - I like that.
I found that package in the tools::R_user_dir() package
Still, if pkgA imports the generic from pkgB, then installing pkgA installs
pkgB and all of its dependencies (Depends and Imports). Which of course makes
sense (as otherwise pkgB cannot be installed). But all of this just for
importing
foo <- function(x, ...)
UseMethod("foo")
from pkgB.
Be
Thanks Hong - I like that.
I found that package in the tools::R_user_dir() package - us that the one?
Rainer
> On 23 Jun 2020, at 15:07, Hong Ooi wrote:
>
> Another possibility, if you want the jar to be dynamic and also have a
> standard location for it, is to write it to the R config/user
Another possibility, if you want the jar to be dynamic and also have a standard
location for it, is to write it to the R config/user dir. This is available via
R_user_dir() in R 4.0 (and earlier versions via the backports package). An
older alternative that still works is to use the rappdirs pac
It's described in ?library; tere is also a post on the R-blog at
https://developer.r-project.org/Blog/public/2019/03/19/managing-search-path-conflicts/index.html
Best,
luke
On Tue, 23 Jun 2020, Kevin R. Coombes wrote:
Wait; I have options on how to configure conflict resolution? Can you tell
Thanks Duncan.
> On 23 Jun 2020, at 14:35, Duncan Murdoch wrote:
>
> Your assumption that .jar files are not allowed is wrong: a number of
> packages contain them: rscala, J4R, Rbgs, bartMachine, OpenStreetMap, ...
> There's a specific mention about how to include them in the CRAN policy
>
Wait; I have options on how to configure conflict resolution? Can you
tell me where to read more about this feature?
Thanks,
Kevin
On 6/22/2020 10:51 PM, luke-tier...@uiowa.edu wrote:
On Tue, 23 Jun 2020, Bert Gunter wrote:
"Users don't get warned about overriding names in packages they've
Your assumption that .jar files are not allowed is wrong: a number of
packages contain them: rscala, J4R, Rbgs, bartMachine, OpenStreetMap,
... There's a specific mention about how to include them in the CRAN
policy document:
"For Java .class and .jar files, the sources should be in a top-l
Hi
I have a package called `plantuml` (https://github.com/rkrug/plantuml) which
converts plantuml code to UML graphs. It uses for this the java program
https://plantuml.com which is Open Source.
As it is not allowed to distribute a binary with an R package, I use the
approach of a function wh
On 23/06/2020 4:22 a.m., Guido Schwarzer wrote:
Am 23.06.20 um 10:00 schrieb Viechtbauer, Wolfgang (SP):
[...]
@Neal: A separate package with generic functions that pkgA and pkgB could
import is an interesting suggestion, thanks!
What makes this interesting is that there is no dependency on o
On 22/06/2020 10:17 p.m., Bert Gunter wrote:
"Users don't get warned about overriding names in packages they've
loaded, because that would just be irritating."
Is that also true if the package or generic is imported by another that
they load; or is a dependency of a package they load? If so, I
Am 23.06.20 um 10:00 schrieb Viechtbauer, Wolfgang (SP):
[...]
@Neal: A separate package with generic functions that pkgA and pkgB could
import is an interesting suggestion, thanks!
What makes this interesting is that there is no dependency on other
packages in generics.
Remains the questio
Thanks to all who replied and provided input.
@Duncan: Yes, of course there is the note about masking. In my experience, many
people won't understand what this means, what the consequences are, and that
pkgA::foo(x) and pkgB::foo(x) are workarounds. And yes, pkgA importing the
foo() generic fro
16 matches
Mail list logo
