Re: [R-pkg-devel] How to account for optional packages not necessarily on CRAN
Thanks Dirk! I did not realize that suggested packages are not required
to be on primary repos like CRAN, BioC. We do indeed condition our code
to check that. So I guess, we are good to go, as is.
I will, in due time, read the paper too...
-N
On 12/10/19 5:52 PM, Dirk Eddelbuettel wrote:
On 10 December 2019 at 17:22, Balasubramanian Narasimhan wrote:
| We've run into the following problem in integrating commercial and open
| source solvers in to our package CVXR. We have "Suggests" dependency on
| some packages that may not be available to CRAN.
|
| There are two main scenarios.
|
| 1. A suggested meta-package is on CRAN, e.g. Rmosek, but the user must
| further take action to ensure the binary is installed. The recommended
| requireNamespace("Rmosek", quietly = TRUE) is insufficient to guarantee
| the functionality desired even if it succeeds.
|
| 2. A suggested package is on github or a commercial vendor site only.
| The package code has references to such packages in the code, causing
| problems while checking on CRAN.
|
| It would seem, at least for 2 above, that separating the suggested
| functionality into other packages can ensure that birds of the same
| feather can flock together. But the shared internals make this
| impossible to do at the moment.
|
| The only thing I can think of is to ask CRAN to consider
| _R_FORCE_CHECK_SUGGESTS_= 0 for such a package. Am I missing anything?
You could use drat (or, if you prefer, roll a CRAN repo by hand) to host a
"CRAN-alike" repo on, say, GitHub or any other http(s)-accessible site, and
then use Additional_repository: with it.
Brooke and I have a fully worked in example for the case of large data
packages in the R Journal:
https://journal.r-project.org/archive/2017/RJ-2017-026/index.html
Hosting Data Packages via drat: A Case Study with Hurricane Exposure Data
G. Brooke Anderson and Dirk Eddelbuettel , The R Journal (2017) 9:1, pages
486-497.
Abstract Data-only packages offer a way to provide extended functionality
for other R users. However, such packages can be large enough to exceed
the package size limit (5 megabytes) for the Comprehen sive R Archive
Network (CRAN). As an alternative, large data packages can be posted to
additional repostiories beyond CRAN itself in a way that allows smaller
code packages on CRAN to access and use the data. The drat package
facilitates creation and use of such alternative repositories and makes it
particularly simple to host them via GitHub. CRAN packages can draw on
packages posted to drat repositories through the use of the
‘Additonal_repositories’ field in the DESCRIPTION file. This paper
describes how R users can create a suite of coordinated packages, in which
larger data packages are hosted in an alternative repository created with
drat, while a smaller code package that interacts with this data is
created that can be submitted to CRAN.
Don't be misled by 'data' here--it works the same way with code. And it is
the _one_ option you have because Suggests: are not required to be on a
primary repo like CRAN or BioC. Naturally, you then need to condition your
code on "is it here yet?" but you likely already do.
Hope this helps, Dirk
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] How to account for optional packages not necessarily on CRAN
On 10 December 2019 at 17:22, Balasubramanian Narasimhan wrote:
| We've run into the following problem in integrating commercial and open
| source solvers in to our package CVXR. We have "Suggests" dependency on
| some packages that may not be available to CRAN.
|
| There are two main scenarios.
|
| 1. A suggested meta-package is on CRAN, e.g. Rmosek, but the user must
| further take action to ensure the binary is installed. The recommended
| requireNamespace("Rmosek", quietly = TRUE) is insufficient to guarantee
| the functionality desired even if it succeeds.
|
| 2. A suggested package is on github or a commercial vendor site only.
| The package code has references to such packages in the code, causing
| problems while checking on CRAN.
|
| It would seem, at least for 2 above, that separating the suggested
| functionality into other packages can ensure that birds of the same
| feather can flock together. But the shared internals make this
| impossible to do at the moment.
|
| The only thing I can think of is to ask CRAN to consider
| _R_FORCE_CHECK_SUGGESTS_= 0 for such a package. Am I missing anything?
You could use drat (or, if you prefer, roll a CRAN repo by hand) to host a
"CRAN-alike" repo on, say, GitHub or any other http(s)-accessible site, and
then use Additional_repository: with it.
Brooke and I have a fully worked in example for the case of large data
packages in the R Journal:
https://journal.r-project.org/archive/2017/RJ-2017-026/index.html
Hosting Data Packages via drat: A Case Study with Hurricane Exposure Data
G. Brooke Anderson and Dirk Eddelbuettel , The R Journal (2017) 9:1, pages
486-497.
Abstract Data-only packages offer a way to provide extended functionality
for other R users. However, such packages can be large enough to exceed
the package size limit (5 megabytes) for the Comprehen sive R Archive
Network (CRAN). As an alternative, large data packages can be posted to
additional repostiories beyond CRAN itself in a way that allows smaller
code packages on CRAN to access and use the data. The drat package
facilitates creation and use of such alternative repositories and makes it
particularly simple to host them via GitHub. CRAN packages can draw on
packages posted to drat repositories through the use of the
‘Additonal_repositories’ field in the DESCRIPTION file. This paper
describes how R users can create a suite of coordinated packages, in which
larger data packages are hosted in an alternative repository created with
drat, while a smaller code package that interacts with this data is
created that can be submitted to CRAN.
Don't be misled by 'data' here--it works the same way with code. And it is
the _one_ option you have because Suggests: are not required to be on a
primary repo like CRAN or BioC. Naturally, you then need to condition your
code on "is it here yet?" but you likely already do.
Hope this helps, Dirk
--
http://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-pkg-devel] How to account for optional packages not necessarily on CRAN
We've run into the following problem in integrating commercial and open
source solvers in to our package CVXR. We have "Suggests" dependency on
some packages that may not be available to CRAN.
There are two main scenarios.
1. A suggested meta-package is on CRAN, e.g. Rmosek, but the user must
further take action to ensure the binary is installed. The recommended
requireNamespace("Rmosek", quietly = TRUE) is insufficient to guarantee
the functionality desired even if it succeeds.
2. A suggested package is on github or a commercial vendor site only.
The package code has references to such packages in the code, causing
problems while checking on CRAN.
It would seem, at least for 2 above, that separating the suggested
functionality into other packages can ensure that birds of the same
feather can flock together. But the shared internals make this
impossible to do at the moment.
The only thing I can think of is to ask CRAN to consider
_R_FORCE_CHECK_SUGGESTS_= 0 for such a package. Am I missing anything?
Thank you.
-Naras
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] inconsistent behavior between R CMD check and interactive use
So I am looking. and it is even worse than what you suggest.
library()
shows that both HH and microplot are in both the system and personal libraries
Packages in library 'C:/Program Files/R/R-devel/library':
HH Version: 3.1-34
microplot Version: 1.0-15
Everything else in the system library belongs there.
Neither of these is the current CRAN version.
Packages in library 'C:/Users/rmh.DESKTOP-60G4CCO/R/win-library/4.0':
HH Version: 3.1-39 ## 3.1-37 is the current CRAN version
microplot Version: 1.0-42 ## this is the current CRAN version
I removed the ancient HH and microplot from c:/Program Files/R/R-devel/library
I left the correct current versions of both in
c:/Users/rmh.DESKTOP-60G4CCO/R/win-library/4.0
Then I ran the R CMD check again.
R CMD check --run-dontrun --as-cran HH_3.1-39.tar.gz
Very strange results:
"
* checking examples ... ERROR
Running examples in 'HH-Ex.R' failed
The error occurred in:
R Under development (unstable) (2019-12-05 r77528) -- "Unsuffered Consequences"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> pkgname <- "HH"
> source(file.path(R.home("share"), "R", "examples-header.R"))
> options(warn = 1)
> options(pager = "console")
> base::assign(".ExTimings", "HH-Ex.timings", pos = 'CheckExEnv')
> base::cat("name\tuser\tsystem\telapsed\n", file=base::get(".ExTimings", pos =
> 'CheckExEnv'))
> base::assign(".format_ptime",
+ function(x) {
+ if(!is.na(x[4L])) x[1L] <- x[1L] + x[4L]
+ if(!is.na(x[5L])) x[2L] <- x[2L] + x[5L]
+ options(OutDec = '.')
+ format(x[1L:3L], digits = 7L)
+ },
+ pos = 'CheckExEnv')
>
> ### *
> library('HH')
Error in library("HH") : there is no package called 'HH'
Execution halted
* checking PDF version of manual ... OK
* checking for non-standard things in the check directory ... OK
* checking for detritus in the temp directory ... OK
* DONE
Status: 1 ERROR
See
'x:/HOME/rmh/HH-R.package/HH.Rcheck/00check.log'
for details.
"
it tested the new version until it got to examples. Then it wanted to
run the examples
from the system library version.
Next try.
I will copy the current version (3.1-39, the one I am testing) of just
HH to the system library and run the check again.
That works! It did a proper check of the correct version of the package.
R-devel seems to have a new check. it is detecting files written not
in the temp directory.
I was doing so in several \dontrun{} examples, but I will fix them
before actually submitting to CRAN.
Thank you Duncan.
Rich
On Tue, Dec 10, 2019 at 2:27 PM Duncan Murdoch wrote:
>
> (Rich, you've heard this already, this message is for others:)
>
> I think I've found the cause of this, and it might be a bug in the check
> code in R.
>
> Rich's package HH "Suggests" microplot, and microplot "Imports" HH.
> When running checks on the new version 3.1-38 of HH it appears the tests
> from the new version are run but the code being run is from the previous
> version 3.1-37 which is on CRAN. I installed the old version
> indirectly when I installed microplot before running check.
>
> I've only seen this on Windows in R-devel when running --as-cran. It
> doesn't happen in R-devel on MacOS with or without --as-cran, and I
> don't think it happens on Windows without --as-cran (but it might just
> be that there are no symptoms of testing the wrong version in that case).
>
> A workaround is to explicitly remove HH, then install the new version
> before running the check code.
>
> Duncan Murdoch
>
>
>
>
>
> On 08/12/2019 10:33 p.m., Richard M. Heiberger wrote:
> > Duncan,
> >
> > Thank you offering to look.
> > I have tried all the obvious things that I could think of. None helped.
> > Perhaps you will think of something I haven't tried
> >
> > The reproducible example (not minimal) I can suggest is to use the
> > submitted file.
> >
> > ftp://CRAN.R-project.org/incoming/archive/HH_3.1-38.tar.gz
> >
> > On my windows machine
> >
> > R CMD check --as-cran HH_3.1-38.tar.gz
> > halts with
> >> BB <- likert(tmp[2:6,], box.width=unit(.4,"cm"), positive.order=TRUE)
> > Error in apply(x, 3:ldx, function(x) list(x)) :
> >'MARGIN' does not match dim(X)
> > Calls: likert ... as.MatrixList -> as.MatrixList.array -> lapply -> apply
> > Execution halted
> >
> > This is wrong. That problem was in 3.1-37 and is why I needed a new
> > version.
> > I repaired that problem. Running interactively, that command succeeds
> > on my
Re: [R-pkg-devel] inconsistent behavior between R CMD check and interactive use
(Rich, you've heard this already, this message is for others:)
I think I've found the cause of this, and it might be a bug in the check
code in R.
Rich's package HH "Suggests" microplot, and microplot "Imports" HH.
When running checks on the new version 3.1-38 of HH it appears the tests
from the new version are run but the code being run is from the previous
version 3.1-37 which is on CRAN. I installed the old version
indirectly when I installed microplot before running check.
I've only seen this on Windows in R-devel when running --as-cran. It
doesn't happen in R-devel on MacOS with or without --as-cran, and I
don't think it happens on Windows without --as-cran (but it might just
be that there are no symptoms of testing the wrong version in that case).
A workaround is to explicitly remove HH, then install the new version
before running the check code.
Duncan Murdoch
On 08/12/2019 10:33 p.m., Richard M. Heiberger wrote:
Duncan,
Thank you offering to look.
I have tried all the obvious things that I could think of. None helped.
Perhaps you will think of something I haven't tried
The reproducible example (not minimal) I can suggest is to use the
submitted file.
ftp://CRAN.R-project.org/incoming/archive/HH_3.1-38.tar.gz
On my windows machine
R CMD check --as-cran HH_3.1-38.tar.gz
halts with
BB <- likert(tmp[2:6,], box.width=unit(.4,"cm"), positive.order=TRUE)
Error in apply(x, 3:ldx, function(x) list(x)) :
'MARGIN' does not match dim(X)
Calls: likert ... as.MatrixList -> as.MatrixList.array -> lapply -> apply
Execution halted
This is wrong. That problem was in 3.1-37 and is why I needed a new version.
I repaired that problem. Running interactively, that command succeeds
on my machine.
R CMD check --as-cran --run-dontrun HH_3.1-38.tar.gz
halts with
tmp.data <- confintervaldata()
Error in confintervaldata() : could not find function "confintervaldata"
Execution halted
That is wrong. confintervaldata is in the NAMESPACE.
Running interactively, that command succeeds.
I added an ls("package:HH") ## yes I spelled it correctly
and the confinervaldata is missing from the list. Again, it is in the
NAMESPACE for the generated executable package.
On the CRAN machines, neither of these problems appeared. Instead
they found a different error
from code analysis, not from an execution failure. I don't understand
why I didn't get that issue on
my machine when I used --as-cran. The repair is in 3.1-39, which I
haven't sent in yet.
The repair is to replace
class(xxx) == "try-error"
with
"try-error" %in% class(xxx)
Please let me know if you see these same problems, or if you can think
of something else to try.
Rich
On Sun, Dec 8, 2019 at 4:58 PM Duncan Murdoch wrote:
On 08/12/2019 3:14 p.m., Richard M. Heiberger wrote:
I am seeing this in
version
_
platform x86_64-w64-mingw32
arch x86_64
os mingw32
system x86_64, mingw32
status Under development (unstable)
major 4
minor 0.0
year 2019
month 12
day05
svn rev77528
language R
version.string R Under development (unstable) (2019-12-05 r77528)
nickname Unsuffered Consequences
I also saw this in 2019-12-03 r77513
In my interactive use I set
Sys.setenv("_R_CLASS_MATRIX_ARRAY_"="true")
to match what --as-cran does for class(matrix(1))
There are two problems, unrelated I think.
1. I have an example which works correctly in interactive use and which
shows an error under R CMD check. The error message is the one we now expect
when class(matrix(1)) is just "matrix". The error should not be
triggered when the class
is c("matrix","array") >
2. I export many functions. Several are not handled correctly during
R CMD check testing.
They appear in the NAMESPACE in the source, and also in both the
Rcheck 00_pkg_src and the Rcheck built package.
Yet, when those functions are called during the testing of the
examples, they aren't visible.
An ls() call inserted into the \examples{} section does not include them.
ls() wouldn't normally see functions exported from packages. You'd need
ls("package:foo") to see the exports from package foo, and that only
works after attaching the package. But examples should be running with
your package attached during testing, so if that's what you really
meant, then you do have a problem.
The functions are visible and work correctly during interactive use.
I am running a WIndows 10 system inside a Parallels Virtual Machine on
a Macintosh.
Has anyone else seen similar misbehavior?
Or can suggest a repair?
Not seen this, and can't suggest a repair without seeing a reproducible
example.
Duncan
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Additional issues: OpenBLAS
Dear package developers, I have an 'additional issue' listed on CRAN for my package mfbvar (https://cran.r-project.org/web/checks/check_results_mfbvar.html). The issue exists for the following configuration: * using R Under development (unstable) (2019-11-19 r77437) * using platform: x86_64-pc-linux-gnu (64-bit) and OpenBLAS. The re-building of the vignette output fails for a function that uses RcppArmadillo. The failure occurs because of a column index being out of bounds, but this is an effect of the problem and not the cause (e.g. due to NAs). I have not experienced this failure on win builder, r-hub or Travis where I have used various versions of R and Windows, Linux, OS X (although not OpenBLAS). I am a little bit at a loss how to handle the situation as I cannot debug, I want to keep the vignette, and I want the package to be retained on CRAN. Any ideas as to how I should go about solving the issue? Best, Sebastian N�r du har kontakt med oss p� Uppsala universitet med e-post s� inneb�r det att vi behandlar dina personuppgifter. F�r att l�sa mer om hur vi g�r det kan du l�sa h�r: http://www.uu.se/om-uu/dataskydd-personuppgifter/ E-mailing Uppsala University means that we will process your personal data. For more information on how this is performed, please read here: http://www.uu.se/en/about-uu/data-protection-policy [[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] Error while checking if Pandoc is available
Furthermore, I think you can simply use
rmarkdown::pandoc_available("1.12.3") to answer both questions (is pandoc
available, is the particular version or a later version available).
Maëlle.
Den fredag 6 december 2019 17:30:28 CET, Henrik Bengtsson
skrev:
Hugh is correct. To clarify, update
if (!rmarkdown::pandoc_available() || rmarkdown::pandoc_version() < "1.12.3") {
stop("'brinton' requires Pandoc v < 1.12.3 (https://pandoc.org/)")
}
The reason is that when using 'a || b', expression 'b' will NOT be
evaluated if 'a' is not TRUE. In contrast, when you use 'a | b',
expression 'b' will be evaluated regardless of outcome of 'a'.
A good rule of thumb is: If you expect your OR or AND statements to
give a single/scalar TRUE of FALSE, use || or &&. This is commonly
used in if(), and while() conditions.
/Henrik
On Fri, Dec 6, 2019 at 4:18 AM Hugh Parsonage wrote:
>
> Change | to ||
>
> On Fri, 6 Dec 2019 at 11:08 pm, Pere Millan Martinez
> wrote:
>
> > Yesterday the publication of the new brinton package war archived
> > (https://cran.r-project.org/web/packages/brinton/index.html) because the
> > following line produces the following error:
> >
> > if(rmarkdown::pandoc_available() == FALSE | rmarkdown::pandoc_version()
> > < "1.12.3") {stop("'brinton' requires Pandoc v < 1.12.3
> > (https://pandoc.org/)")}
> >
> > Error in if (rmarkdown::pandoc_available() == FALSE |
> > rmarkdown::pandoc_version() <:
> > argument is of length zero
> >
> > The checks of the knitr package produce similar errors
> > (https://cran.r-hub.io/web/checks/check_results_knitr.html) but knitr is
> > available in CRAN (furtunatelly).
> > Also, I have been punished by prof. Brian Ripley so I can not resubmit
> > the package until January.
> >
> > Do you have any clue about how to fix this? Does to punish rookies have
> > sense in this case?
> >
> > Thanks in advance,
> > -Pere Millán
> >
> >
> >
> > On 10/11/2019 11:31, Pere Millan Martinez wrote:
> > > Hello,
> > >
> > > I'm trying to submit a first version of the brinton package but the
> > > CRAN-pretest on Debian produces the following NOTE:
> > >
> > > Check: for detritus in the temp directory, Result: NOTE
> > > Found the following files/directories :
> > > ‘calibre_4.2.0_tmp_BPGKxL’ ‘calibre_4.2.0_tmp_D8BXMj’
> > > ‘calibre_4.2.0_tmp_M8RU75’ ‘calibre_4.2.0_tmp_TipWj0’
> > > ‘calibre_4.2.0_tmp_f0mVQS’ ‘calibre_4.2.0_tmp_fHEPce’
> > > ‘runtime-hornik’
> > >
> > > The 'brinton' package stores files in the temporary folder (which I
> > > think is ok) but I can not figure out
> > > the relationship between the files that are stored with
> > > 'calibre_4.2.0'. Is this note a false positive or this
> > > is something that I should fix prior to submit?
> > >
> > > Thank you,
> > > Pere Millán-Martínez
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > 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
__
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] default col.names from data.frame not the same as as.data.frame
Hello, All: What names should be given a matrix or data.frame that does not have names for use in "glm.fit"? I ask for two reasons: * "base" R is inconsistent: "data.frame(matrix(1:2, 1))" defaults to "X1", "X2" but "as.data.frame(matrix(1:2, 1))" defaults to "V1", "V2". * I want to use a toy example like this in the documentation for "BMA:::bic.glm.matrix" and "BMA:::bic.glm.data.frame", and since "base" R is inconsistent, I felt a need to ask a group like this for their preferences. Thanks, Spencer Graves __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
