Re: [R-pkg-devel] Error in loadNamespace(x) : there is no package called 'formatR'
> 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 matches my understanding as well (and I think he's >>> contributed more recently than I have). >>> >>> The way non-Sweave vignettes work is that some packages register >>> themselves to recognize vignette files in the vignettes directory. The >>> default one recognizes .Rnw files as vignettes (and a few other >>> extensions too); the knitr::rmarkdown one recognizes .Rmd files and some >>> others. The only way for a package's registration code to be called is >>> for it to be listed as a VignetteBuilder. See ?tools::vignetteEngine >>> for details of the engine. >> >> Can one of you please fix WRE then? The part that says >> >> "...then knitr provides the engine but both knitr and rmarkdown are >> needed for using it, so both these packages need to be in the >> ‘VignetteBuilder’ field..." >> > No, neither of us are members of R Core. Only R Core can edit the manuals. > Duncan Murdoch I've (finaly) followed this thread to here ((too many e-mails, too many ...)). I think I have understood what you wrote and why R Core should change WRE in this part. Notably as I have not written it, there needs to be consultation --> Forwarding to R-core ((i.e., a very rare cross-post !)) Thank you, very much for the discussion, Gábor, Henrik and Duncan! Martin -- Martin Maechler ETH Zurich and R Core team __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Best practise in including third party code
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 with a lot dependencies itself? Is it advisable or ok to only use the according third party source code snippet and cite the other package (of course if the license of the package allows it; own package is AGPL, third package is GPL)? Or should the third party package always be installed as a dependency? I want to avoid bloating the installation process but it is very important for me not to violate academic standards, intellectual properties and best practise. Thanks, Wolfgang __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Debugging library.dynam to include a manual shared object
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 src/* into a .so (and a .dylib and a
.dll none of which you need to explicitly, a huge win for you)
- A package knows how to load a dynamic library declared in NAMESPACE
| Building this works fine in RStudio with devtools::load_all('.'), but when
| I try to run R CMD INSTALL, I get the error: package or namespace load
| failed in library.dynam(lib, package, package.lib): shared object
| 'filename.so' not found.
Only `R CMD INSTALL` matters here for (scripted) CRAN operations. If that
fails you have a problem, no matter how helpful the optional tools are.
| Is there any way I can debug library.dynam to see where it's looking for my
| .so and why it can't find it? Thanks for your help!
As said, R knows where to find a package's shared library file. For the rest,
it is (on Linux) ld.so and its documentation but you (as far as I can
remember) cannot set LD_LIBRARY_PATH from within a running R session.
It might help if you described your problem in more detail with a
reproducible example.
Regards, Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Debugging library.dynam to include a manual shared object
> 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 Boshnakov
-Original Message-
From: R-package-devel On Behalf Of Dirk
Eddelbuettel
Sent: 18 November 2020 12:57
To: Jon Davidson
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Debugging library.dynam to include a manual shared
object
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 src/* into a .so (and a .dylib and a
.dll none of which you need to explicitly, a huge win for you)
- A package knows how to load a dynamic library declared in NAMESPACE
| Building this works fine in RStudio with devtools::load_all('.'), but
| when I try to run R CMD INSTALL, I get the error: package or namespace
| load failed in library.dynam(lib, package, package.lib): shared object
| 'filename.so' not found.
Only `R CMD INSTALL` matters here for (scripted) CRAN operations. If that fails
you have a problem, no matter how helpful the optional tools are.
| Is there any way I can debug library.dynam to see where it's looking
| for my .so and why it can't find it? Thanks for your help!
As said, R knows where to find a package's shared library file. For the rest,
it is (on Linux) ld.so and its documentation but you (as far as I can
remember) cannot set LD_LIBRARY_PATH from within a running R session.
It might help if you described your problem in more detail with a reproducible
example.
Regards, Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
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] Best practise in including third party code
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 other improvements in the upstream code. cheers Ben Bolker On Wed, Nov 18, 2020 at 5:45 AM Wolfgang Lenhard wrote: > > 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 with a lot > dependencies itself? Is it advisable or ok to only use the according > third party source code snippet and cite the other package (of course if > the license of the package allows it; own package is AGPL, third package > is GPL)? Or should the third party package always be installed as a > dependency? I want to avoid bloating the installation process but it is > very important for me not to violate academic standards, intellectual > properties and best practise. > > Thanks, > Wolfgang > > __ > 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
