Excuses for the length of this, but optimx has a lot of packages
using it.
Over the past couple of months, I have been struggling with checking
a new, and much augmented, optimx package. It offers some serious
improvements:
- parameter scaling on all methods
- two safeguarded Newton methods
- improved gradient approximations
- more maintainable structure for adding new solvers in future
- a single method "solver" (wrapper) that uses optim() syntax
However, I have been going through a lot of bother with reverse
dependency checking. In summary, tools::check_packages and
devtools::revdep_check both give lots of complaints, in particular
about packages that cannot be installed. When I run my own checks
(see below), I get no issues that reflect on my own package. Similarly,
Duncan Murdoch was very helpful and ran a check on an earlier version
with no major issues using his own check program. I have noticed,
or been told, that several other workers have their own procedures
and that they have experienced somewhat similar difficulties.
Unfortunately, my last effort to submit to CRAN got blocked at the
pre-scan stage because of reverse dependencies. I have not been able
to fix what I cannot find, however, as it appears I am getting caught
on an obstacle outside my control. I did not get a response from the
CRAN team, but the timing was in the middle of the R3.5 launch, so
understandable. However, I am very reluctant to use submission to
CRAN as a checking tool.
My questions:
1) Am I missing something in my method of calling tools or devtools?
The code is included below. Or not reading the output carefully?
I will be happy to put detail on a website -- too large for here.
2) Is it time to consider an effort to provide online revdep checking
that would avoid pressure on CRAN team directly and would provide
clearer indicators of the issues raised by a particular package? I'd
be happy to assist in such an effort, as it appears to be needed, and
with appropriate output and links could aid developers to improve
their packages.
Cheers,
John Nash
tools::check_packages_in_dir finds install fail for
BioGeoBEARS
CensSpatial
Countr
ecd
ldhmm
LifeHist
macc
marked
midasr
QuantumClone
spfrontier
surrosurv
Code:
# cranrevdep
require(tools)
pkgdir <- "~/temp/wrkopt/srcpkg"
jcheck<-check_packages_in_dir(pkgdir,
check_args = c("--as-cran", ""),
reverse = list(repos = getOption("repos")["CRAN"]))
summary(jcheck)
-
devtools::revdep_check finds install fail for:
afex
IRTpp
lme4
as well as
BioGeoBEARS
CensSpatial
Countr
ecd
ldhmm
LifeHist
macc
marked
midasr
QuantumClone
spfrontier
surrosurv
Summary:
Saving check results to `revdep/check.rds`
---
Cleaning up
--
* Failed to install: afex, BioGeoBEARS, CensSpatial, Countr, ecd, IRTpp, ldhmm,
LifeHist, lme4, macc, marked, midasr,
QuantumClone, spfrontier, surrosurv
* ACDm: checking compilation flags used ... WARNING
* languageR: checking Rd cross-references ... WARNING
* mvord: checking compilation flags used ... WARNING
* RandomFields: checking compilation flags used ... WARNING
* rankdist: checking compilation flags used ... WARNING
* regsem: checking compilation flags used ... WARNING
21 packages with problems
|package |version | errors| warnings| notes|
|:|:---|--:|:|-:|
|ACDm |1.0.4 | 0|1| 1|
|afex |0.21-2 | 1|0| 0|
|BioGeoBEARS |0.2.1 | 1|0| 0|
|CensSpatial |1.3 | 1|0| 0|
|Countr |3.4.1 | 1|0| 0|
|ecd |0.9.1 | 1|0| 0|
|IRTpp|0.2.6.1 | 1|0| 0|
|languageR|1.4.1 | 0|1| 4|
|ldhmm|0.4.5 | 1|0| 0|
|LifeHist |1.0-1 | 1|0| 0|
|lme4 |1.1-17 | 1|0| 0|
|macc |1.0.1 | 1|0| 0|
|marked |1.2.1 | 1|0| 0|
|midasr |0.6 | 1|0| 0|
|mvord|0.3.1 | 0|1| 0|
|QuantumClone |1.0.0.6 | 1|0| 0|
|RandomFields |3.1.50 | 0|1| 2|
|rankdist |1.1.3 | 0|1| 0|
|regsem |1.1.2 | 0|1| 0|
|spfrontier |0.2.3 | 1|0| 0|
|surrosurv|1.1.24 | 1|0| 0|
But there are 43 dependencies, so must we assume rest are OK?
> require(devtools)
Loading required package: devtools
> rdlist <- revdep()
> rdlist
[1] "ACDm" "afex" "bbmle"
[4] "BioGeoBEARS" "calibrar" "CatDyn"
[7] "CensSpatial" "CJAMP" "Countr"
[10] "dimRed""ecd"
