Re: [R-pkg-devel] [EXTERNAL] Proper CRAN way - How to handle dependency of java jar file?

[Rainer M Krug]

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 
> 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 - 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 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 
> package.
> 
> 
> -Original Message-
> From: R-package-devel  > On Behalf Of Rainer M Krug
> Sent: Tuesday, 23 June 2020 10:48 PM
> To: Duncan Murdoch  >
> Cc: R Package Devel  >
> Subject: [EXTERNAL] Re: [R-pkg-devel] Proper CRAN way - How to handle 
> dependency of java jar file?
> 
> 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 
> document:
> 
> That’s good to know.
> 
> 
> 
> "For Java .class and .jar files, the sources should be in a top-level java 
> directory in the source package (or that directory should explain how they 
> can be obtained)."
> 
> So a tet file in the inst/jar directory giving the link to the GitHub repo 
> would be fine in this case?
> 
> 
> 
> If you still decide not to include your .jar file (maybe it is too big, for 
> example),
> 
> 
> I guess it would be stretching it a bit, as the jar file is 8.2 MB, and 
> plantuml has regular continuous updates, so I would prefer to keep it dynamic.
> 
> 
> 
> then I think your option 1 is unusable for those people who can't write to 
> the library location because of permission problems. (Admin privileges are 
> often necessary to install packages in the main library.)  Generally I think 
> everyone can install packages somewhere, but users do really get confused 
> when they have multiple library locations, possibly each containing a 
> different version of a package.
> 
> So the suggested option would be to have a function, which 
> 1) ask the user to create a directory in the home folder 
> 2) download the jar file into that directory or, when no permission is 
> granted, into the tmpdir()
> 
> Thanks, no major changes necessary for that,
> 
> Rainer
> 
> 
> 
> 
> Duncan Murdoch
> 
> On 23/06/2020 8:18 a.m., Rainer M Krug wrote:
> 
> 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 which downloads the jar file into the directory 
> `system.file("jar/plantuml.jar", package = "plantuml”)`.
> This works nicely, and at the moment, the function is called automatically 
> before the plantuml.jar is used.
> Now I would like to submit the package to CRAN. I can’t find the guidelines 
> anymore, so I am asking here:
> What is the appropriate way of handling this?
> I can think of a at least two ways of making it obvious to the user, that a 
> binary is downloaded:
> 1) if the file plantuml.jar is not present, ask the user to run the function 
> `updatePlantumlJar()` which downloads the jar to the original location in the 
> package directory
> 2) tell the user to download the file manually and to put it somewhere, where 
> the package will find it
> I would prefer the first version, as the plantuml.jar would be in the package 
> directory, where usually nobody but the package is doing stuff.
> Any suggestions on how I could make this “CRAN conform”?
> Thanks a lot,
> Rainer
> --
> Rainer M. Krug, 

Re: [R-pkg-devel] [External] Re: Two packages with the same generic function

[Bert Gunter]

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
with another generic of the same name that is exported.

At least that's my understanding. However, this discussion is getting too
esoteric for me, so I'm just going to shut up and leave it to folks who are
more knowledgeable. With apologies for my noise.

Bert Gunter

"The trouble with having an open mind is that people keep coming along and
sticking things into it."
-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )


On Tue, Jun 23, 2020 at 7:29 AM Viechtbauer, Wolfgang (SP) <
wolfgang.viechtba...@maastrichtuniversity.nl> 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 importing
>
> foo <- function(x, ...)
>UseMethod("foo")
>
> from pkgB.
>
> Best,
> Wolfgang
>
> >-Original Message-
> >From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
> >Behalf Of Duncan Murdoch
> >Sent: Tuesday, 23 June, 2020 12:25
> >To: Guido Schwarzer; r-package-devel@r-project.org
> >Subject: Re: [R-pkg-devel] [External] Re: Two packages with the same
> generic
> >function
> >
> >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 other
> >> packages in generics.
> >>
> >> Remains the question which help page would be shown for help(foo).
> >
> >If a package imports and then exports the generic, it would normally
> >create a help page referring to the original one where the generic is
> >defined.  So both pkgA and pkgB would probably both create help pages,
> >and the help system would show a page listing them both plus the generic
> >one, and asking the user to choose.
> >
> >An example happens if you use
> >
> >library(broom)
> >?tidy
> >
> >The broom package links to a page that says "These objects are imported
> >from other packages. Follow the links below to see their documentation."
> >One of the links is to the ?tidy page in the generics package.
> >
> >You are allowed to say ?broom::tidy, and then you don't go to the list
> >of possibilities, you go directly to the one you asked for.
> >
> >Duncan Murdoch
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [External] Re: Two packages with the same generic function

[Duncan Murdoch]

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 
importing

foo <- function(x, ...)
UseMethod("foo")

from pkgB.


I think you'd need to be more specific about the two packages before I 
would believe this is much of a problem.


If pkgA and pkgB both contain methods for the same generic, then they 
are probably working in the same problem domain, and already share many 
dependencies.  It seems it would be rare that pkgA's dependencies and 
pkgB's dependencies are both big sets that don't have a lot of overlap.


If it's only pkgB that has the big dependency set, then just put the 
generic in pkgA.  And if you really are in that rare case where they 
both have big non-overlapping dependency sets, then create a tiny pkgC 
to hold the generic.


On the other hand, if both packages were allowed to declare foo as a 
generic, and R should think of it as the same generic, confusion would 
follow:


Think about the case of the filter functions in stats and dplyr.  It's 
not a generic in stats, but obviously could be.  In stats, the name is 
used to talk about linear filtering on a time series. (There are several 
different representations of time series in R, so it might make sense 
for stats::filter to be a generic to allow it to work on all of them.)


In dplyr, the same name is used to describe subsetting a dataset.

Those are both valid uses of the word "filter", but they have nothing to 
do with each other.  It's perfectly reasonable to think that a user 
might want to do both kinds of filtering.  If stats::filter was a 
generic and someone wrote a method for dplyr::filter, clearly a call to 
stats::filter should not use that method. It's even possible that some 
package doing time series analysis in the tidyverse framework would want 
to have methods for both generics.


Duncan Murdoch




Best,
Wolfgang


-Original Message-
From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
Behalf Of Duncan Murdoch
Sent: Tuesday, 23 June, 2020 12:25
To: Guido Schwarzer; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] [External] Re: Two packages with the same generic
function

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 other
packages in generics.

Remains the question which help page would be shown for help(foo).


If a package imports and then exports the generic, it would normally
create a help page referring to the original one where the generic is
defined.  So both pkgA and pkgB would probably both create help pages,
and the help system would show a page listing them both plus the generic
one, and asking the user to choose.

An example happens if you use

library(broom)
?tidy

The broom package links to a page that says "These objects are imported
from other packages. Follow the links below to see their documentation."
One of the links is to the ?tidy page in the generics package.

You are allowed to say ?broom::tidy, and then you don't go to the list
of possibilities, you go directly to the one you asked for.

Duncan Murdoch


__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [EXTERNAL] Proper CRAN way - How to handle dependency of java jar file?

[Hong Ooi via R-package-devel]

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 - us that the one?

Rainer



On 23 Jun 2020, at 15:07, Hong Ooi 
mailto:hong...@microsoft.com>> 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 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 package.


-Original Message-
From: R-package-devel 
mailto:r-package-devel-boun...@r-project.org>>
 On Behalf Of Rainer M Krug
Sent: Tuesday, 23 June 2020 10:48 PM
To: Duncan Murdoch mailto:murdoch.dun...@gmail.com>>
Cc: R Package Devel 
mailto:r-package-devel@r-project.org>>
Subject: [EXTERNAL] Re: [R-pkg-devel] Proper CRAN way - How to handle 
dependency of java jar file?

Thanks Duncan.


On 23 Jun 2020, at 14:35, Duncan Murdoch 
mailto:murdoch.dun...@gmail.com>> 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 document:

That’s good to know.



"For Java .class and .jar files, the sources should be in a top-level java 
directory in the source package (or that directory should explain how they can 
be obtained)."

So a tet file in the inst/jar directory giving the link to the GitHub repo 
would be fine in this case?



If you still decide not to include your .jar file (maybe it is too big, for 
example),


I guess it would be stretching it a bit, as the jar file is 8.2 MB, and 
plantuml has regular continuous updates, so I would prefer to keep it dynamic.



then I think your option 1 is unusable for those people who can't write to the 
library location because of permission problems. (Admin privileges are often 
necessary to install packages in the main library.)  Generally I think everyone 
can install packages somewhere, but users do really get confused when they have 
multiple library locations, possibly each containing a different version of a 
package.

So the suggested option would be to have a function, which
1) ask the user to create a directory in the home folder
2) download the jar file into that directory or, when no permission is granted, 
into the tmpdir()

Thanks, no major changes necessary for that,

Rainer




Duncan Murdoch

On 23/06/2020 8:18 a.m., Rainer M Krug wrote:

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 which downloads the jar file into the directory 
`system.file("jar/plantuml.jar", package = "plantuml”)`.
This works nicely, and at the moment, the function is called automatically 
before the plantuml.jar is used.
Now I would like to submit the package to CRAN. I can’t find the guidelines 
anymore, so I am asking here:
What is the appropriate way of handling this?
I can think of a at least two ways of making it obvious to the user, that a 
binary is downloaded:
1) if the file plantuml.jar is not present, ask the user to run the function 
`updatePlantumlJar()` which downloads the jar to the original location in the 
package directory
2) tell the user to download the file manually and to put it somewhere, where 
the package will find it
I would prefer the first version, as the plantuml.jar would be in the package 
directory, where usually nobody but the package is doing stuff.
Any suggestions on how I could make this “CRAN conform”?
Thanks a lot,
Rainer
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)
Orcid ID: -0002-7490-0066
Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland
Office:   +41 (0)44 635 47 64
Cell:  +41 (0)78 630 66 57
email:  rainer.k...@uzh.ch
   rai...@krugs.de
Skype: 

Re: [R-pkg-devel] [External] Re: Two packages with the same generic function

[Viechtbauer, Wolfgang (SP)]

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.

Best,
Wolfgang

>-Original Message-
>From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
>Behalf Of Duncan Murdoch
>Sent: Tuesday, 23 June, 2020 12:25
>To: Guido Schwarzer; r-package-devel@r-project.org
>Subject: Re: [R-pkg-devel] [External] Re: Two packages with the same generic
>function
>
>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 other
>> packages in generics.
>>
>> Remains the question which help page would be shown for help(foo).
>
>If a package imports and then exports the generic, it would normally
>create a help page referring to the original one where the generic is
>defined.  So both pkgA and pkgB would probably both create help pages,
>and the help system would show a page listing them both plus the generic
>one, and asking the user to choose.
>
>An example happens if you use
>
>library(broom)
>?tidy
>
>The broom package links to a page that says "These objects are imported
>from other packages. Follow the links below to see their documentation."
>One of the links is to the ?tidy page in the generics package.
>
>You are allowed to say ?broom::tidy, and then you don't go to the list
>of possibilities, you go directly to the one you asked for.
>
>Duncan Murdoch

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [EXTERNAL] Proper CRAN way - How to handle dependency of java jar file?

[Rainer M Krug]

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 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 
> package.
> 
> 
> -Original Message-
> From: R-package-devel  On Behalf Of 
> Rainer M Krug
> Sent: Tuesday, 23 June 2020 10:48 PM
> To: Duncan Murdoch 
> Cc: R Package Devel 
> Subject: [EXTERNAL] Re: [R-pkg-devel] Proper CRAN way - How to handle 
> dependency of java jar file?
> 
> 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 
>> document:
> 
> That’s good to know.
> 
>> 
>> "For Java .class and .jar files, the sources should be in a top-level java 
>> directory in the source package (or that directory should explain how they 
>> can be obtained)."
> 
> So a tet file in the inst/jar directory giving the link to the GitHub repo 
> would be fine in this case?
> 
>> 
>> If you still decide not to include your .jar file (maybe it is too big, for 
>> example),
> 
> 
> I guess it would be stretching it a bit, as the jar file is 8.2 MB, and 
> plantuml has regular continuous updates, so I would prefer to keep it dynamic.
> 
> 
>> then I think your option 1 is unusable for those people who can't write to 
>> the library location because of permission problems. (Admin privileges are 
>> often necessary to install packages in the main library.)  Generally I think 
>> everyone can install packages somewhere, but users do really get confused 
>> when they have multiple library locations, possibly each containing a 
>> different version of a package.
> 
> So the suggested option would be to have a function, which 
> 1) ask the user to create a directory in the home folder 
> 2) download the jar file into that directory or, when no permission is 
> granted, into the tmpdir()
> 
> Thanks, no major changes necessary for that,
> 
> Rainer
> 
> 
>> 
>> Duncan Murdoch
>> 
>> On 23/06/2020 8:18 a.m., Rainer M Krug wrote:
>>> 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 which downloads the jar file into the directory 
>>> `system.file("jar/plantuml.jar", package = "plantuml”)`.
>>> This works nicely, and at the moment, the function is called automatically 
>>> before the plantuml.jar is used.
>>> Now I would like to submit the package to CRAN. I can’t find the guidelines 
>>> anymore, so I am asking here:
>>> What is the appropriate way of handling this?
>>> I can think of a at least two ways of making it obvious to the user, that a 
>>> binary is downloaded:
>>> 1) if the file plantuml.jar is not present, ask the user to run the 
>>> function `updatePlantumlJar()` which downloads the jar to the original 
>>> location in the package directory
>>> 2) tell the user to download the file manually and to put it somewhere, 
>>> where the package will find it
>>> I would prefer the first version, as the plantuml.jar would be in the 
>>> package directory, where usually nobody but the package is doing stuff.
>>> Any suggestions on how I could make this “CRAN conform”?
>>> Thanks a lot,
>>> Rainer
>>> --
>>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
>>> UCT), Dipl. Phys. (Germany)
>>> Orcid ID: -0002-7490-0066
>>> Department of Evolutionary Biology and Environmental Studies
>>> University of Zürich
>>> Office Y34-J-74
>>> Winterthurerstrasse 190
>>> 8075 Zürich
>>> Switzerland
>>> Office: +41 (0)44 635 47 64
>>> Cell:   +41 (0)78 630 66 57
>>> email:  rainer.k...@uzh.ch
>>> rai...@krugs.de
>>> Skype: RMkrug
>>> PGP: 0x0F52F982
>>> --
>>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
>>> UCT), Dipl. Phys. (Germany)
>>> Orcid ID: -0002-7490-0066
>>> Department of Evolutionary Biology and Environmental Studies
>>> University of Zürich
>>> Office Y34-J-74
>>> Winterthurerstrasse 190
>>> 8075 Zürich
>>> Switzerland
>>> Office: +41 (0)44 635 47 64
>>> Cell:   +41 (0)78 630 66 57
>>> email:  rainer.k...@uzh.ch
>>> rai...@krugs.de
>>> Skype: RMkrug
>>> PGP: 0x0F52F982
>>> __
>>> R-package-devel@r-project.org mailing list
>>> 

Re: [R-pkg-devel] [EXTERNAL] Re: Proper CRAN way - How to handle dependency of java jar file?

[Hong Ooi via R-package-devel]

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 package.


-Original Message-
From: R-package-devel  On Behalf Of 
Rainer M Krug
Sent: Tuesday, 23 June 2020 10:48 PM
To: Duncan Murdoch 
Cc: R Package Devel 
Subject: [EXTERNAL] Re: [R-pkg-devel] Proper CRAN way - How to handle 
dependency of java jar file?

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 
> document:

That’s good to know.

> 
> "For Java .class and .jar files, the sources should be in a top-level java 
> directory in the source package (or that directory should explain how they 
> can be obtained)."

So a tet file in the inst/jar directory giving the link to the GitHub repo 
would be fine in this case?
 
> 
> If you still decide not to include your .jar file (maybe it is too big, for 
> example),


I guess it would be stretching it a bit, as the jar file is 8.2 MB, and 
plantuml has regular continuous updates, so I would prefer to keep it dynamic.


> then I think your option 1 is unusable for those people who can't write to 
> the library location because of permission problems. (Admin privileges are 
> often necessary to install packages in the main library.)  Generally I think 
> everyone can install packages somewhere, but users do really get confused 
> when they have multiple library locations, possibly each containing a 
> different version of a package.

So the suggested option would be to have a function, which 
1) ask the user to create a directory in the home folder 
2) download the jar file into that directory or, when no permission is granted, 
into the tmpdir()

Thanks, no major changes necessary for that,

Rainer
 

> 
> Duncan Murdoch
> 
> On 23/06/2020 8:18 a.m., Rainer M Krug wrote:
>> 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 which downloads the jar file into the directory 
>> `system.file("jar/plantuml.jar", package = "plantuml”)`.
>> This works nicely, and at the moment, the function is called automatically 
>> before the plantuml.jar is used.
>> Now I would like to submit the package to CRAN. I can’t find the guidelines 
>> anymore, so I am asking here:
>> What is the appropriate way of handling this?
>> I can think of a at least two ways of making it obvious to the user, that a 
>> binary is downloaded:
>> 1) if the file plantuml.jar is not present, ask the user to run the function 
>> `updatePlantumlJar()` which downloads the jar to the original location in 
>> the package directory
>> 2) tell the user to download the file manually and to put it somewhere, 
>> where the package will find it
>> I would prefer the first version, as the plantuml.jar would be in the 
>> package directory, where usually nobody but the package is doing stuff.
>> Any suggestions on how I could make this “CRAN conform”?
>> Thanks a lot,
>> Rainer
>> --
>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
>> UCT), Dipl. Phys. (Germany)
>> Orcid ID: -0002-7490-0066
>> Department of Evolutionary Biology and Environmental Studies
>> University of Zürich
>> Office Y34-J-74
>> Winterthurerstrasse 190
>> 8075 Zürich
>> Switzerland
>> Office:  +41 (0)44 635 47 64
>> Cell:+41 (0)78 630 66 57
>> email:  rainer.k...@uzh.ch
>>  rai...@krugs.de
>> Skype: RMkrug
>> PGP: 0x0F52F982
>> --
>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
>> UCT), Dipl. Phys. (Germany)
>> Orcid ID: -0002-7490-0066
>> Department of Evolutionary Biology and Environmental Studies
>> University of Zürich
>> Office Y34-J-74
>> Winterthurerstrasse 190
>> 8075 Zürich
>> Switzerland
>> Office:  +41 (0)44 635 47 64
>> Cell:+41 (0)78 630 66 57
>> email:  rainer.k...@uzh.ch
>>  rai...@krugs.de
>> Skype: RMkrug
>> PGP: 0x0F52F982
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office: +41 (0)44 635 47 64
Cell: 

Re: [R-pkg-devel] [External] Re: Two packages with the same generic function

[luke-tierney]

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 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
loaded, because that would just be irritating."


All Duncan is saying is that you don't get a notification if you do

    mean <- log

in the interpreter. If you attach a package that does this you would
get a notification (or an error if you configure your conflict
resolution options appropriately).

Best,

luke



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel



--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Proper CRAN way - How to handle dependency of java jar file?

[Rainer M Krug]

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 
> document:

That’s good to know.

> 
> "For Java .class and .jar files, the sources should be in a top-level java 
> directory in the source package (or that directory should explain how they 
> can be obtained)."

So a tet file in the inst/jar directory giving the link to the GitHub repo 
would be fine in this case?
 
> 
> If you still decide not to include your .jar file (maybe it is too big, for 
> example),


I guess it would be stretching it a bit, as the jar file is 8.2 MB, and 
plantuml has regular continuous updates, so I would prefer to keep it dynamic.


> then I think your option 1 is unusable for those people who can't write to 
> the library location because of permission problems. (Admin privileges are 
> often necessary to install packages in the main library.)  Generally I think 
> everyone can install packages somewhere, but users do really get confused 
> when they have multiple library locations, possibly each containing a 
> different version of a package.

So the suggested option would be to have a function, which 
1) ask the user to create a directory in the home folder 
2) download the jar file into that directory or, when no permission is granted, 
into the tmpdir()

Thanks, no major changes necessary for that,

Rainer
 

> 
> Duncan Murdoch
> 
> On 23/06/2020 8:18 a.m., Rainer M Krug wrote:
>> 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 which downloads the jar file into the directory 
>> `system.file("jar/plantuml.jar", package = "plantuml”)`.
>> This works nicely, and at the moment, the function is called automatically 
>> before the plantuml.jar is used.
>> Now I would like to submit the package to CRAN. I can’t find the guidelines 
>> anymore, so I am asking here:
>> What is the appropriate way of handling this?
>> I can think of a at least two ways of making it obvious to the user, that a 
>> binary is downloaded:
>> 1) if the file plantuml.jar is not present, ask the user to run the function 
>> `updatePlantumlJar()` which downloads the jar to the original location in 
>> the package directory
>> 2) tell the user to download the file manually and to put it somewhere, 
>> where the package will find it
>> I would prefer the first version, as the plantuml.jar would be in the 
>> package directory, where usually nobody but the package is doing stuff.
>> Any suggestions on how I could make this “CRAN conform”?
>> Thanks a lot,
>> Rainer
>> --
>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
>> UCT), Dipl. Phys. (Germany)
>> Orcid ID: -0002-7490-0066
>> Department of Evolutionary Biology and Environmental Studies
>> University of Zürich
>> Office Y34-J-74
>> Winterthurerstrasse 190
>> 8075 Zürich
>> Switzerland
>> Office:  +41 (0)44 635 47 64
>> Cell:+41 (0)78 630 66 57
>> email:  rainer.k...@uzh.ch
>>  rai...@krugs.de
>> Skype: RMkrug
>> PGP: 0x0F52F982
>> --
>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
>> UCT), Dipl. Phys. (Germany)
>> Orcid ID: -0002-7490-0066
>> Department of Evolutionary Biology and Environmental Studies
>> University of Zürich
>> Office Y34-J-74
>> Winterthurerstrasse 190
>> 8075 Zürich
>> Switzerland
>> Office:  +41 (0)44 635 47 64
>> Cell:+41 (0)78 630 66 57
>> email:  rainer.k...@uzh.ch
>>  rai...@krugs.de
>> Skype: RMkrug
>> PGP: 0x0F52F982
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office: +41 (0)44 635 47 64
Cell:   +41 (0)78 630 66 57
email:  rainer.k...@uzh.ch
rai...@krugs.de
Skype: RMkrug

PGP: 0x0F52F982




[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [External] Re: Two packages with the same generic function

[Kevin R. Coombes]

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
loaded, because that would just be irritating."


All Duncan is saying is that you don't get a notification if you do

    mean <- log

in the interpreter. If you attach a package that does this you would
get a notification (or an error if you configure your conflict
resolution options appropriately).

Best,

luke



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Proper CRAN way - How to handle dependency of java jar file?

[Duncan Murdoch]

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-level 
java directory in the source package (or that directory should explain 
how they can be obtained)."


If you still decide not to include your .jar file (maybe it is too big, 
for example), then I think your option 1 is unusable for those people 
who can't write to the library location because of permission problems. 
(Admin privileges are often necessary to install packages in the main 
library.)  Generally I think everyone can install packages somewhere, 
but users do really get confused when they have multiple library 
locations, possibly each containing a different version of a package.


Duncan Murdoch

On 23/06/2020 8:18 a.m., Rainer M Krug wrote:

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 which downloads the jar file into the directory 
`system.file("jar/plantuml.jar", package = "plantuml”)`.

This works nicely, and at the moment, the function is called automatically 
before the plantuml.jar is used.

Now I would like to submit the package to CRAN. I can’t find the guidelines 
anymore, so I am asking here:

What is the appropriate way of handling this?

I can think of a at least two ways of making it obvious to the user, that a 
binary is downloaded:

1) if the file plantuml.jar is not present, ask the user to run the function 
`updatePlantumlJar()` which downloads the jar to the original location in the 
package directory

2) tell the user to download the file manually and to put it somewhere, where 
the package will find it

I would prefer the first version, as the plantuml.jar would be in the package 
directory, where usually nobody but the package is doing stuff.

Any suggestions on how I could make this “CRAN conform”?

Thanks a lot,

Rainer

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office: +41 (0)44 635 47 64
Cell:   +41 (0)78 630 66 57
email:  rainer.k...@uzh.ch
rai...@krugs.de
Skype: RMkrug

PGP: 0x0F52F982





--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office: +41 (0)44 635 47 64
Cell:   +41 (0)78 630 66 57
email:  rainer.k...@uzh.ch
rai...@krugs.de
Skype: RMkrug

PGP: 0x0F52F982

__
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

[R-pkg-devel] Proper CRAN way - How to handle dependency of java jar file?

[Rainer M Krug]

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 which downloads the jar file into the directory 
`system.file("jar/plantuml.jar", package = "plantuml”)`. 

This works nicely, and at the moment, the function is called automatically 
before the plantuml.jar is used.

Now I would like to submit the package to CRAN. I can’t find the guidelines 
anymore, so I am asking here: 

What is the appropriate way of handling this?

I can think of a at least two ways of making it obvious to the user, that a 
binary is downloaded:

1) if the file plantuml.jar is not present, ask the user to run the function 
`updatePlantumlJar()` which downloads the jar to the original location in the 
package directory

2) tell the user to download the file manually and to put it somewhere, where 
the package will find it

I would prefer the first version, as the plantuml.jar would be in the package 
directory, where usually nobody but the package is doing stuff.

Any suggestions on how I could make this “CRAN conform”?

Thanks a lot,

Rainer

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office: +41 (0)44 635 47 64
Cell:   +41 (0)78 630 66 57
email:  rainer.k...@uzh.ch
rai...@krugs.de
Skype: RMkrug

PGP: 0x0F52F982





--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office: +41 (0)44 635 47 64
Cell:   +41 (0)78 630 66 57
email:  rainer.k...@uzh.ch
rai...@krugs.de
Skype: RMkrug

PGP: 0x0F52F982

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [External] Re: Two packages with the same generic function

[Duncan Murdoch]

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 other
packages in generics.

Remains the question which help page would be shown for help(foo).


If a package imports and then exports the generic, it would normally 
create a help page referring to the original one where the generic is 
defined.  So both pkgA and pkgB would probably both create help pages, 
and the help system would show a page listing them both plus the generic 
one, and asking the user to choose.


An example happens if you use

library(broom)
?tidy

The broom package links to a page that says "These objects are imported 
from other packages. Follow the links below to see their documentation."

One of the links is to the ?tidy page in the generics package.

You are allowed to say ?broom::tidy, and then you don't go to the list 
of possibilities, you go directly to the one you asked for.


Duncan Murdoch

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Two packages with the same generic function

[Duncan Murdoch]

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 would not 
call it "just irritating" because if silent, how would they know?


I can't think of an example where this would be a problem.  If a package 
imports objects from another package, it doesn't affect the user's 
search list.  Maybe it affects what methods are available, but I can't 
see how it would change what generics are available.


Can you give an example of what you're worried about?

Duncan Murdoch




Bert Gunter

"The trouble with having an open mind is that people keep coming along 
and sticking things into it."

-- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )


On Mon, Jun 22, 2020 at 5:58 PM Mark Leeds > wrote:


Hi Duncan: I maintain dynlm and your example is the exact reason
I've been
getting emails from people regarding
it not working correctly. I've been telling them to load dplyr by using

library(dplyr, exclude = c("filter", "lag"))





On Mon, Jun 22, 2020 at 7:57 PM Duncan Murdoch
mailto:murdoch.dun...@gmail.com>>
wrote:

 > On 22/06/2020 3:48 p.m., Tom Wainwright wrote:
 > > Yet another alternative is simply to prevent your second
package from
 > > overriding the previously defined generic. The basic problem is
the ease
 > > with which R allows overriding prior generic definitions (one
of those
 > bits
 > > of bad behavior we in the USA used to call "a Bozo No-No"),
which hides
 > all
 > > the previous methods, as demonstrated by the following code:
 > >
 > >> plot(1:3)
 > >>> plot <- function(x, ...) UseMethod("plot")
 > >>> plot(1:3)
 > >> Error in UseMethod("plot") :
 > >>    no applicable method for 'plot' applied to an object of class
 > >> "c('integer', 'numeric')"
 > >>> rm(plot)
 > >>> plot(1:3)
 > >
 > >
 > > (Despite Murdoch's suggestion that overriding the generic
SHOULD issue a
 > > warning, it doesn't seem to in R 4.0.1.)
 >
 > Sure it does, if pkgA and pkgB both export the same name, then
you get a
 > warning when you attach the second one.  For example,
 >
 >  > library(MASS)
 >  > library(dplyr)
 >
 > Attaching package: ‘dplyr’
 >
 > The following object is masked from ‘package:MASS’:
 >
 >      select
 >
 > The following objects are masked from ‘package:stats’:
 >
 >      filter, lag
 >
 > The following objects are masked from ‘package:base’:
 >
 >      intersect, setdiff, setequal, union
 >
 > Users don't get warned about overriding names in packages they've
 > loaded, because that would just be irritating.
 >
 > Duncan Murdoch
 >
 > >
 > > So, we might try protecting the generic definitions of "foo" in
both
 > > packages by enclosing them in something like:
 > >
 > > tryCatch(invisible(methods("foo")), error = {foo <- function(x,...)
 > >> UseMethod("foo")}, finally=NULL)
 > >
 > >
 > > There's probably a more elegant way to accomplish this. This
relies on
 > > "methods" returning an error if "foo" has no defined methods,
so it is
 > not
 > > redefined if their are previous methods. I haven't had time to
try this
 > in
 > > the two-package example, but it might work, although I'm not
sure how to
 > > handle the Namespace declarations.
 > >
 > >    Tom Wainwright
 > >
 > > On Mon, Jun 22, 2020 at 10:41 AM Bert Gunter
mailto:bgunter.4...@gmail.com>>
 > wrote:
 > >
 > >> ...
 > >> and just to add to the query, assume the author of pkg B did
(does) not
 > >> know of pkg A and so, for example, could (did) not import any
of pkg A's
 > >> content into B. Given that there are at the moment ~20,000
packages out
 > >> there, this does not seem to be an unreasonable assumption.
One may even
 > >> further assume that the user may not know that (s)he has package B
 > loaded,
 > >> as it may be a dependency of another package that (s)he uses. I
 > certainly
 > >> don't keep track of all the dependencies of packages I use.
 > >>
 > >> Under these assumptions, is there any more convenient
alternative to
 > >> Wolfgang's pkgA:foo(x) explicit call under such assumptions?
If pkgA
 > has a
 > >> long name, what might one do?
 > >>
 > >> Bert Gunter
 > >>
 > >> "The trouble with having an open mind is that people keep
coming along
 > and
 > >> sticking things into it."
 > >> -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
 > >>
 > >>
 > >> On Mon, 

Re: [R-pkg-devel] [External] Re: Two packages with the same generic function

[Guido Schwarzer]

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 question which help page would be shown for help(foo).

Best, Guido

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [External] Re: Two packages with the same generic function

[Viechtbauer, Wolfgang (SP)]

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 from pkgB or vice-versa is an obvious solution.

@Bert: Related to the suggestion that one package could import the generic from 
the other, you raise an important point. This in essence adds a whole package 
as a dependency for these two lines of code:

foo <- function(x, ...)
   UseMethod("foo")

And let's say pkgA imports this from pkgB and pkgB depends on 10 other 
packages? Does this mean that pkgA has now added 11 packages as dependencies 
for importing 2 lines of code? If so, that seems quite undesirable to me.

@Neal: A separate package with generic functions that pkgA and pkgB could 
import is an interesting suggestion, thanks!

@Tom: I might need some time to process what you are suggesting. What I am 
really hoping for (and not sure if your approach can handle this) is that the 
following works regardless of the order in which pkgA and pkgB are loaded:

x <- 1:4
class(x) <- "A"
foo(x)
class(x) <- "B"
foo(x)

Again, that used to be the case in R 3.6.3, but not anymore in 4.0.x.

Best,
Wolfgang

>-Original Message-
>From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On
>Behalf Of Bert Gunter
>Sent: Tuesday, 23 June, 2020 4:55
>To: luke-tier...@uiowa.edu
>Cc: r-package-devel@r-project.org
>Subject: Re: [R-pkg-devel] [External] Re: Two packages with the same generic
>function
>
>OK. Thanks.
>
>Bert Gunter
>
>On Mon, Jun 22, 2020 at 7:51 PM  wrote:
>
>> On Tue, 23 Jun 2020, Bert Gunter wrote:
>>
>> > "Users don't get warned about overriding names in packages they've
>> > loaded, because that would just be irritating."
>>
>> All Duncan is saying is that you don't get a notification if you do
>>
>>  mean <- log
>>
>> in the interpreter. If you attach a package that does this you would
>> get a notification (or an error if you configure your conflict
>> resolution options appropriately).
>>
>> Best,
>>
>> luke
>>
>> >
>> > 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 would not
>> > call it "just irritating" because if silent, how would they know?
>> >
>> >
>> > Bert Gunter
>> >
>> > "The trouble with having an open mind is that people keep coming along
>> and
>> > sticking things into it."
>> > -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip )
>> >
>> >
>> > On Mon, Jun 22, 2020 at 5:58 PM Mark Leeds  wrote:
>> >
>> >> Hi Duncan: I maintain dynlm and your example is the exact reason I've
>> been
>> >> getting emails from people regarding
>> >> it not working correctly. I've been telling them to load dplyr by using
>> >>
>> >> library(dplyr, exclude = c("filter", "lag"))
>> >>
>> >> On Mon, Jun 22, 2020 at 7:57 PM Duncan Murdoch <
>> murdoch.dun...@gmail.com>
>> >> wrote:
>> >>
>> >>> On 22/06/2020 3:48 p.m., Tom Wainwright wrote:
>>  Yet another alternative is simply to prevent your second package from
>>  overriding the previously defined generic. The basic problem is the
>> >> ease
>>  with which R allows overriding prior generic definitions (one of
>those
>> >>> bits
>>  of bad behavior we in the USA used to call "a Bozo No-No"), which
>> hides
>> >>> all
>>  the previous methods, as demonstrated by the following code:
>> 
>> > plot(1:3)
>> >> plot <- function(x, ...) UseMethod("plot")
>> >> plot(1:3)
>> > Error in UseMethod("plot") :
>> >no applicable method for 'plot' applied to an object of class
>> > "c('integer', 'numeric')"
>> >> rm(plot)
>> >> plot(1:3)
>> 
>>  (Despite Murdoch's suggestion that overriding the generic SHOULD
>issue
>> >> a
>>  warning, it doesn't seem to in R 4.0.1.)
>> >>>
>> >>> Sure it does, if pkgA and pkgB both export the same name, then you get
>> a
>> >>> warning when you attach the second one.  For example,
>> >>>
>> >>> > library(MASS)
>> >>> > library(dplyr)
>> >>>
>> >>> Attaching package: ‘dplyr’
>> >>>
>> >>> The following object is masked from ‘package:MASS’:
>> >>>
>> >>>  select
>> >>>
>> >>> The following objects are masked from ‘package:stats’:
>> >>>
>> >>>  filter, lag
>> >>>
>> >>> The following objects are masked from ‘package:base’:
>> >>>
>> >>>  intersect, setdiff, setequal, union
>> >>>
>> >>> Users don't get warned about overriding names in packages they've
>> >>> loaded, because that would just be irritating.
>> >>>
>> >>> Duncan Murdoch
>> 
>>  So, we might try protecting the generic definitions of "foo" in both
>>  packages by enclosing them in something like:
>> 
>>  tryCatch(invisible(methods("foo")), error = {foo <- function(x,...)
>> > UseMethod("foo")}, finally=NULL)
>> 
>> 
>>  There's