Re: [R-pkg-devel] Best practise in including third party code

2020-11-18 Thread Ben Bolker
I would recommend copying the snippet/minor function into your own code, with attribution/citation (and, as a courtesy, e-mailing the maintainer of the package to let them know). The only disadvantage I can think of in this approach is that you won't automatically benefit from bug fixes or

Re: [R-pkg-devel] Debugging library.dynam to include a manual shared object

2020-11-18 Thread Georgi Boshnakov
> Building this works fine in RStudio with devtools::load_all('.'), but > | when I try to run R CMD INSTALL,... Note that the devtools equivalents of 'R CMD build/check/install' are devtools::build(), devtools::check(), devtools::install(). devtools::load_all() has a different purpose. Georgi

Re: [R-pkg-devel] Debugging library.dynam to include a manual shared object

2020-11-18 Thread Dirk Eddelbuettel
Jon, On 16 November 2020 at 12:27, Jon Davidson wrote: | I am trying to build an R package with a manually compiled .so file. To do | so, I have included a call to useDynLib() in my NAMESPACE file. In general you would not need to do that, or do that: - A package knows how to turn files in

[R-pkg-devel] Best practise in including third party code

2020-11-18 Thread Wolfgang Lenhard
Dear R developer list, in general, if functionality from other packages are used in one's own package, it is of course the best way to declare the other package as an import. What is the straight forward way for only minor functions or functionality, especially when the other package comes

Re: [R-pkg-devel] Error in loadNamespace(x) : there is no package called 'formatR'

2020-11-18 Thread Martin Maechler
> Duncan Murdoch > on Fri, 13 Nov 2020 17:45:44 -0500 writes: > On 13/11/2020 4:32 p.m., Gábor Csárdi wrote: >> On Fri, Nov 13, 2020 at 9:02 PM Duncan Murdoch wrote: >> [...] >>> Things may have changed since Henrik and I wrote the code, but his >>> description