Re: [R-pkg-devel] Suppressing long-running vignette code in CRAN submission
Produce a PDF file yourself, then use the "as.is" feature of the R.rsp
package.
Specifically, include this line in your DESCRIPTION file:
VignetteBuilder: R.rsp
Let's say the pdf file is called "myfile.pdf". Create a file called
"myfile.pdf.asis" that contains the vignette instructions. Put it in the
vignette directory along with the PDF file. Mine looks like:
%\VignetteIndexEntry{PUT VIGNETTE TITLE HERE}
%\VignetteKeywords{PUT KEYWORDS HERE}
%\VignetteDepends{PACKAGE_NAME}
%\VignettePackage{PACKAGE_NAME}
%\VignetteEngine{R.rsp::asis}
I am not certain if this works for an HTML vignette, but I see no reason
why it shouldn't.
Best,
Kevin
On 10/16/2023 10:14 AM, John Fox wrote:
Dear list members,
I believe that this issue has been discussed previously, but I'm not
sure that I have the solution right.
Georges Monette and I have developed a package that we intend to
submit soon to CRAN which has a vignette including code that takes a
long time to run. The sources for the package are available at
.
We figure that we have to suppress running the code the vignette when
CRAN checks the package or the check time will be excessive.
The vignette is written as a .Rmd file to be compiled by knitr,
producing an HTML vignette. The top of the .Rmd file looks like this:
--- snip ---
---
title: "Cross-validation of regression models"
author: "John Fox and Georges Monette"
date: "`r Sys.Date()`"
package: cv
output:
rmarkdown::html_vignette:
fig_caption: yes
bibliography: ["cv.bib"]
csl: apa.csl
vignette: >
%\VignetteIndexEntry{Cross-validation of regression models}
%\VignetteEngine{knitr::rmarkdown}
%\VignetteEncoding{UTF-8}
---
```{r setup, include = FALSE}
knitr::opts_chunk$set(
collapse = TRUE,
message = TRUE,
warning = TRUE,
fig.align = "center",
fig.height = 6,
fig.width = 7,
fig.path = "fig/",
dev = "png",
comment = "#>",
eval = nzchar(Sys.getenv("REBUILD_CV_VIGNETTES"))
)
### other irrelevant setup code not shown ###
```
--- snip ---
So (near the bottom), if the environment variable REBUILD_CV_VIGNETTES
isn't empty, the code blocks in the vignette are evaluated, otherwise
not. To build the tarball for the package to be submitted to CRAN, we
will set REBUILD_CV_VIGNETTES to "true". That works as intended.
If we submit the tarball to CRAN, I believe that the package as
distributed by CRAN will include the HTML vignette from our tarball,
showing the evaluated code blocks, but when CRAN checks the package,
these long-running code blocks will not be executed (because
REBUILD_CV_VIGNETTES will not exist on the CRAN check machines).
My questions:
Is that correct?
If not, how can we ensure that the complete vignette is distributed by
CRAN without causing an overly long CRAN check time?
In particular, we don't want CRAN to rebuild and distribute the
vignette, because the resulting HTML file won't show the evaluated code.
Any assistance would be appreciated.
Thank you,
John
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] correcting errors in an existing package
1. Yes, remove the "lazyData" line from the DESCRIPTION file.
2. Do you have "stats" in the "Imports" line in the DESCRIPTION file? If
not, put it in along with the "importFrom" line in the NAMESPACE file.
On 3/31/2023 4:51 PM, Dennis Boos wrote:
Recently I got a message from CRAN that my package Monte.Carlo.se (on CRAN
for the last few years) does not pass current testing. There seemed to be
2 problems:
***
1. * checking LazyData ... NOTE
'LazyData' is specified without a 'data' directory
I have this line in my DESCRIPTION file:
LazyData: true
Should I remove that?
*
2. * checking examples with --run-donttest ... [42s/42s] ERROR
Running examples in ‘Monte.Carlo.se-Ex.R’ failed
The error most likely occurred in:
pairwise.se(hold,xcol=10:12,summary.f=cv)
Error: object 'hold' not found
Execution halted
***
So, I put in the R code to generate the data matrix *hold. *But that
brought a host of other errors when checking in Rstudio with
devtools::check("S:/Documents/srcis/a.projects/Monte.Carlo.isr.and.package/Monte.Carlo.se.March.2023")
I started seeing the following list about standard functions like sd.
N checking R code for possible problems (3.4s)
boot.se: no visible global function definition for 'sd'
boot.var: no visible global function definition for 'var'
corr: no visible global function definition for 'cor'
cv: no visible global function definition for 'sd'
ratio.mean.sdhat.sd: no visible global function definition for 'sd'
ratio.mean.vhat.var: no visible global function definition for 'var'
ratio.sd: no visible global function definition for 'sd'
ratio.var: no visible global function definition for 'var'
varn: no visible global function definition for 'var'
Undefined global functions or variables:
cor sd var
Consider adding
importFrom("stats", "cor", "sd", "var")
to your NAMESPACE file.
But you can't add those functions to NAMESPACE. Well I did but
devtools::build()
gets rid of it. Also, I keep getting the message in the Rstudio check
WARNING
'qpdf' is needed for checks on size reduction of PDFs
but I got the latest versions of R and Rstudio and was able to get
qpdf to install and loaded with library(qpdf), but Rstudio still gives
that message.
So, if anybody has any suggestions, I would appreciate it.
Thanks.
Dennis
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Mysterious "invalid z limit"
Did you have to split the packages to get the CI/CD tools to work?
Because,to me, it looks as though I can install multiple different R
packages from the same git project, using something like
library(devtools)
install_gitlab("krcoombes/[PROJECT]", "pkg/[PACKAGE]")
Best,
Kevin
On 1/8/2023 1:38 PM, Spencer Graves wrote:
R-Forge was wonderful for me when I started using it. Then
several years ago, I started having problems like you described. A few
years ago I migrated from R-Forge to GitHub.
One problem I encountered in the transition: On R-Forge, I had
multiple packages in the same R-Forge project. I had to split them
apart for GitHub.
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Mysterious "invalid z limit"
A very helpful answer. For some reason (probably because I have an
ancient perl script that automates the steps i take when building and
checking packages), I keep forgetting that the "tools" package let's me
do these things from within R.
I had already isolated the offending line ("plot(obj)") inside the chunk
where the error occurred, and removed any additional arguments. I
wrapped that line in a "try" command followed by a conditional
"traceback()" to find the problem. This allowed the package build to
knit the vignette and provide some feedback about what was going on. It
turned out that I had copied and pasted an assignment line of the form
main <- [compute the title]
from earlier in the code and pasted it directly as an argument to the
call to image.default. And R did exactly what I told it to (not
surprisingly), and interpreted the value of that assignment as the
unnamed "zlim" option that would have been the corresponding positional
argument that should have been there.
And yes, I still use "left arrow" <- instead of equals = as assignments.
(Heck, I even use emacs and ESS with a leftover keybinding that uses the
underscore key to insert the left arrow. Apparently, I'm ancient myself.)
Kevin
On 1/8/2023 5:04 AM, Duncan Murdoch wrote:
On 07/01/2023 8:43 p.m., Kevin R. Coombes wrote:
Hi,
I am in the middle of developing a new package, which contains a
markdown-knitr-html vignette. When I try to run
R CMD build [mypackagedirectory]
I get an error message
Quitting from lines 330-336
Error: processing vignette failed with diagnostics:
invalid z limits
If I run the same markdown script interactively inside R Studio, there
is no error.
If I knit the markdown script inside R Studio, it produces the correct
HTML output, with no error.
The offending lines of code (the chunk at 330-336) invoke an "image"
method on an object of a class defined in the package, which in turn
computes a matrix from items inside the object and calls image.default,
which is presumably where the error is coming from.
Two questions: (1) How is it possible that the same code works error
free in the RStudio contexts, but fails in the attempt to build the
package?
(2) Any suggestions on how to debug something that only throws an error
from "R CMD build" would be most welcome.
Debugging that sort of thing is hard. Here's what I would try:
From inside an R session, run
tools:::.build_packages("[mypackagedirectory]")
That runs the code that R CMD build runs, so it might trigger the same
error. If so, debug in the usual way, with traceback(), etc.
If that doesn't trigger the error, try it using a different front-end,
e.g. running R at the command line instead of running it in RStudio.
If you still can't trigger it, then start modifying the vignette to
find the exact line that causes the error (e.g. by commenting out the
second half of the code in that chunk; did the error go away? etc.).
Then modify it again to save all the inputs to the bad line in a file
before running it, and see if running that line in a different context
still triggers the error. Etc.
Duncan Murdoch
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Mysterious "invalid z limit"
A terrific answer; thanks. (I am kicking myself for not realizing the answer you gave to question 1. Of course that's the explanation. Too many consecutive hours debugging other items to get to that point, I suppose.) Kevin On 1/8/2023 6:58 AM, Ivan Krylov wrote: On Sat, 7 Jan 2023 20:43:10 -0500 "Kevin R. Coombes" wrote: (1) How is it possible that the same code works error free in the RStudio contexts, but fails in the attempt to build the package? When knitting the vignette from RStudio, it uses the package you already have installed. When knitting the vignette from R CMD build, it uses the code it's about to package. Could it be that your source code is different from the copy installed in your library? (2) Any suggestions on how to debug something that only throws an error from "R CMD build" would be most welcome. R CMD build --no-build-vignettes should let you proceed and get a tarball that could be installed. Hopefully you'll be able to reproduce the error then. __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Mysterious "invalid z limit"
Hi, I am in the middle of developing a new package, which contains a markdown-knitr-html vignette. When I try to run R CMD build [mypackagedirectory] I get an error message Quitting from lines 330-336 Error: processing vignette failed with diagnostics: invalid z limits If I run the same markdown script interactively inside R Studio, there is no error. If I knit the markdown script inside R Studio, it produces the correct HTML output, with no error. The offending lines of code (the chunk at 330-336) invoke an "image" method on an object of a class defined in the package, which in turn computes a matrix from items inside the object and calls image.default, which is presumably where the error is coming from. Two questions: (1) How is it possible that the same code works error free in the RStudio contexts, but fails in the attempt to build the package? (2) Any suggestions on how to debug something that only throws an error from "R CMD build" would be most welcome. Thanks in advance, Kevin __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] function name conflict
Hi, I am writing a package that Imports several other packages. One of my imported packages eventually imports (through a chain of dependencies) "lifecycle", and another eventually imports "rlang". Both "rlang" and "lifecycle" define and export functions called "last_warnings". As a result, when I first execute "library(MYPACKAGE)" in a script, I get a warning of the form " replacing previous import 'lifecycle::last_warnings' by 'rlang::last_warnings' when loading 'tibble' " I don't want the users of MYPACKAGE to have to see this warning (since I know it will spook novices). Is there anything I can do with Imports, Depends, or something else to prevent this warning from occurring? (I know that I can suppress warnings in each script, but I also don't want to explain to my users that they have to do that. Note that I have tried reversing the order of the two functions that I import in the Imports declaration in the DESCRIPTION file, to no effect. I also only use one function from each of the two imported pakages, and they are explicitly listed in importFrom directives in the NAMESPACE file. Thank in advance, Kevin __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Spelling and manual CRAN inspection
That's an excellent idea. I can't resist pointing out that everything that was flagged this morning has been in those packages for years (and for multiple submissions), and has never been flagged before. So I would still have to update my master last this time around. And a human at CRAN would still have to spend time to check the submission comment against the NOTE. (Hmm. Maybe the real underlying issue is that I'd like computers to make less work for humans, not more.) On 7/16/2021 4:43 PM, John Harrold wrote: > I have a list of words, acronyms and initialisms that commonly get > flagged as misspelled words when I submit updates. I generally just > put an explanation for each one in the "optional comment" section of > the submission form. It's pretty simple and seems to work out well. > > On Fri, Jul 16, 2021 at 9:08 AM Kevin R. Coombes > mailto:kevin.r.coom...@gmail.com>> wrote: > > Hi, > > I have been updating a couple of R packages this morning. One > of them > triggered a manual inspection for "possibly mis-spelled words in > DESCRIPTION" for my last name (Coombes) --- even though none of the > other 20 packages that I maintain has ever triggered that particular > NOTE. A second package also triggered a manual inspection for > mis-spelled words including "Proteomics". (These flags only arose > on the > debian CRAN machine, not the Windows CRAN machine, and not on my home > machines. And let's ignore how many spelling corrections I had to make > while typing this email) > > *My question, however, is: why should this NOTE ever trigger a manual > inspection?* That makes more work for the CRAN maintainers, who I am > sure have better things to do than evaluate spelling. Anything that > would actually stop the package from working (mis-spelling a > keyword, or > mis-spelling the name of package that is imported) is going to > cause an > automatic ERROR and a rejection of the submission without making more > work for the CRAN maintainers. The other mis-spellings may reflect > poorly on the package author, but since they are NOTEs, it is easy > enough to get them fixed for the next round without making human > eyeballs look at them. > > Best, > Kevin > > __ > R-package-devel@r-project.org > <mailto:R-package-devel@r-project.org> mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > <https://stat.ethz.ch/mailman/listinfo/r-package-devel> > > > > -- > John > :wq [[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] Spelling and manual CRAN inspection
Hi Jeff, I think you are inferring an attitude in my initial message that wasn't actually present. I greatly appreciate the hard work that CRAN maintainers put in on behalf of the community. And I really did (and do) want to understand why some of their valuable volunteer time should be occupied deciding if "possible mis-spellings" are (a) real and (b) important enough to do something about. I also admit to being possibly the world's worst typist. I often mis-spell multiple words in a sentence, and I rely on numerous spell checkers to point out the problems so I can fix them right away. (But right now, I am unhappy that the spell-checker in my email client insists that "mis-spell" and it variants doesn't have a hyphen in it.) So, I agree that correct spelling is worth someone spending their time on. But that someone (in my opinion) should be the package author and maintainer, not the CRAN maintainers. Part of the issue is that the mis-spellings are reported from R CMD check as a NOTE, not a WARNING nor an ERROR. They don't affect the code in any way (unlike the consequences of trying to import the "grpahics" package -- boy, was that hard to type.). Further, most of the "possible mis-spellings" that I have seen flagged in my own packages are false positives. (As noted above; I use spell-checkers at several points along the way so I can correct them before I submit.) Moreover, the results from different spell-checkers (such as those on different CRAN machines) are inconsistent. That increases the probability that any package is going to get flagged with false positives and require manual intervention. I don't know; maybe the CRAN maintainers like checking other people's spelling manually. But having to do that on a regular basis would soon make me run screaming from the room. Best, Kevin On 7/16/2021 1:07 PM, Jeff Newmiller wrote: Spelling has different importance to different people. You are expressing a value judgement that differs from the values of R Core, but are presenting your opinion as if they are facts. My point is that your challenging attitude IMO makes having a conversation about those concerns difficult. (I am not associated with R Core in any way, and do in fact empathize with your frustration with the process.) I think it is worth pointing out that spelling errors in the DESCRIPTION file are of greater significance than other areas of a package as they can affect assignment of responsibility and permissions, as well as reflecting poorly on the CRAN summary web pages. I suspect that problems with DESCRIPTION files in the past lead to this requirement. I would encourage you to pause for a day or two before sending off messages like this in the future... a lesson I have learned the hard way myself. On July 16, 2021 9:08:27 AM PDT, "Kevin R. Coombes" wrote: Hi, I have been updating a couple of R packages this morning. One of them triggered a manual inspection for "possibly mis-spelled words in DESCRIPTION" for my last name (Coombes) --- even though none of the other 20 packages that I maintain has ever triggered that particular NOTE. A second package also triggered a manual inspection for mis-spelled words including "Proteomics". (These flags only arose on the debian CRAN machine, not the Windows CRAN machine, and not on my home machines. And let's ignore how many spelling corrections I had to make while typing this email) *My question, however, is: why should this NOTE ever trigger a manual inspection?* That makes more work for the CRAN maintainers, who I am sure have better things to do than evaluate spelling. Anything that would actually stop the package from working (mis-spelling a keyword, or mis-spelling the name of package that is imported) is going to cause an automatic ERROR and a rejection of the submission without making more work for the CRAN maintainers. The other mis-spellings may reflect poorly on the package author, but since they are NOTEs, it is easy enough to get them fixed for the next round without making human eyeballs look at them. Best, Kevin __ 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] Spelling and manual CRAN inspection
Hi, I have been updating a couple of R packages this morning. One of them triggered a manual inspection for "possibly mis-spelled words in DESCRIPTION" for my last name (Coombes) --- even though none of the other 20 packages that I maintain has ever triggered that particular NOTE. A second package also triggered a manual inspection for mis-spelled words including "Proteomics". (These flags only arose on the debian CRAN machine, not the Windows CRAN machine, and not on my home machines. And let's ignore how many spelling corrections I had to make while typing this email) *My question, however, is: why should this NOTE ever trigger a manual inspection?* That makes more work for the CRAN maintainers, who I am sure have better things to do than evaluate spelling. Anything that would actually stop the package from working (mis-spelling a keyword, or mis-spelling the name of package that is imported) is going to cause an automatic ERROR and a rejection of the submission without making more work for the CRAN maintainers. The other mis-spellings may reflect poorly on the package author, but since they are NOTEs, it is easy enough to get them fixed for the next round without making human eyeballs look at them. Best, Kevin __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Using ggplot2 within another package
Thanks.
Obviously, long. long ago, (in a galaxy not far enough away), Paul's
suggestion of using "aes_string" was the correct one, since "aes" uses
non-standard evaluation. (And to quote somebody from an R fortune
cookie, "The problem with non-standard evaluation is that it is
non-standard.") But teh documentation at the end oft he link provided by
Robert explivityl tells you not to do that, since "aes_string is
deprecated". And reading more carefully into the manual page for
aes_string, one does indeed find the statement that the function is
"soft deprecated". I'm not sure what that means, other than someone on
the development team doesn't like it.
Instead, the vignette says you should
importFrom("rlang", ".data")
in your NAMESPACE, and write
ggplot(myData, aes(x = .data$myX, y = .data$myY))
And now my dinosaur question: That looks like using one non-standard
hack to cover up the problems with another non-standard hack. Why the
heck is that any better for the developer than writing
ggplot(myData, aes(x = myData$myX, y = myData$myY))
or using Dirk Eddelbuettel's suggestion of calling utils::globalVariables ??
It's time to tell those kids to get off of my lawn.
Kevin
On 4/22/2021 4:45 PM, Robert M. Flight wrote:
> Kevin,
>
> This vignette from ggplot2 itself gives the "officially recommended"
> ways to avoid the warnings from R CMD check
>
> https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html
> <https://ggplot2.tidyverse.org/articles/ggplot2-in-packages.html>
>
> Cheers,
>
> -Robert
>
> On Thu, Apr 22, 2021 at 4:39 PM Paul SAVARY
> mailto:paul.sav...@univ-fcomte.fr>> wrote:
>
> Hi Kevin,
>
> I was faced to the same problem and I used 'aes_string()' instead
> of 'aes()'. You can then just write the name of the columns
> containing the data to plot as character strings.
>
> Example:
>
> myPlot <- function(myData, ...) {
> # get ready
> ggplot(myData, aes_string(x = "myX", y = "myY")) +
> # add my decorations
> theme_bw()
> }
>
> It is probably already the case for your function but you need to
> include #' @import ggplot2 in your function preamble (if I am not
> wrong).
>
> Kind regards
> Paul
>
> - Mail original -
> De: "Kevin R. Coombes" <mailto:kevin.r.coom...@gmail.com>>
> À: "r-package-devel" <mailto:r-package-devel@r-project.org>>
> Envoyé: Jeudi 22 Avril 2021 22:28:55
> Objet: [R-pkg-devel] Using ggplot2 within another package
>
> Hi,
>
> I'm trying to help clean up an R package for someone else to
> submit to
> CRAN. He has used ggplot2 to implement a plotting function for the
> kinds
> of things that his packages generates. His plotting routine basically
> looks like (after changing names to protect the innocent):
>
> myPlot <- fucntion(myData, ...) {
> # get ready
> ggplot(myData, aes(x = myX, y = myY)) +
> # add my decorations
> theme_bw()
> }
>
> Of course, "R CMD check --as-cran" complains that there is no global
> binding for "myX" or "myY" since they are columns defined in the
> data.frame "myData".
>
> What is the best way to work around this issue?
>
> Of course, dinosaurs like myself might be tempted to suggest just
> using
> plain old "plot", so I don't need to see those suggestions.
>
> Do I just ignore the usual ggplot conventions and write "myData$myX"
> inside "aes" in order to appease the CRAN checker? Or is there some
> tidy-er way to solve this problem?
>
> Thanks,
> Kevin
>
> __
> R-package-devel@r-project.org
> <mailto:R-package-devel@r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
>
> __
> R-package-devel@r-project.org
> <mailto:R-package-devel@r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> <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-pkg-devel] Using ggplot2 within another package
Hi,
I'm trying to help clean up an R package for someone else to submit to
CRAN. He has used ggplot2 to implement a plotting function for the kinds
of things that his packages generates. His plotting routine basically
looks like (after changing names to protect the innocent):
myPlot <- fucntion(myData, ...) {
# get ready
ggplot(myData, aes(x = myX, y = myY)) +
# add my decorations
theme_bw()
}
Of course, "R CMD check --as-cran" complains that there is no global
binding for "myX" or "myY" since they are columns defined in the
data.frame "myData".
What is the best way to work around this issue?
Of course, dinosaurs like myself might be tempted to suggest just using
plain old "plot", so I don't need to see those suggestions.
Do I just ignore the usual ggplot conventions and write "myData$myX"
inside "aes" in order to appease the CRAN checker? Or is there some
tidy-er way to solve this problem?
Thanks,
Kevin
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Strange error from CRAN on package submission
Hi Martin, I think you may be right that it is something odd about the configuration on the test machine, since I haven't been able to reproduce it anywhere else. But Duncan did say he could reproduce it in R-devel but not R-4.0.3, so there's that. The error message is buried deep in this thread, but it was: Check: whether package can be installed. Result: WARN Found the following significant warnings: Warning: namespace ‘flexmix’ is not available and has been replaced Check: data for non-ASCII characters Result: WARN Warning: namespace 'flexmix' is not available and has been replaced by .GlobalEnv when processing object '' Best, Kevin On 11/12/2020 10:13 AM, Martin Morgan wrote: This seems more like a problem with the CRAN test machine, with the movMF package installed with flexmix available but loaded with flexmix not available, maybe interacting with a caching mechanism used by the methods package to avoid re-computing methods tables? Otherwise how would movMF ever know to create the flexmix class / method? It seems like this could cause problems for the user if they installed movMV with flexmix available, but removed flexmix. This seems like a subtler variation of 'I installed package A but then removed dependency B and now A doesn't work', which could be a bug in R's remove.packages() but I tried to emulate the scenario of installing movMF and then removing flexmix in an interactive session, and then looking for the warning reported below. I was not successful, but the build report with the error is no longer available so I don't know what I'm looking for... Martin Morgan On 11/11/20, 4:44 PM, "R-package-devel on behalf of Duncan Murdoch" wrote: Here's what I think is happening. In the movMF:::.onLoad function there's a test whether flexmix is installed. If found, then it is loaded and some methods are set. (I'm not sure what caused flexmix to be installed: I didn't intentionally install it, but it ended up in there when I installed enough stuff to check Mercator.) In the R-devel --as-cran checks, some checks are run with only strong dependencies of your package visible. Somehow I think that .onLoad function sees flexmix and loads it, but then some other part of the check can't see it. A workaround is to add flexmix to your Imports clause. This is a strong enough dependency to make it visible, and the error goes away. HOWEVER, to me this is pretty clearly an R-devel bug: you have no control over methods set by packages that you don't even use, so you shouldn't have to change your dependency lists if one of them sets a method that you're using. Duncan Murdoch On 11/11/2020 3:31 p.m., Kevin R. Coombes wrote: > Oh, I forgot to mention explicitly that checking (with --as-cran) on the > development version of R on Windows also produces no errors or warnings. > > On 11/11/2020 1:39 PM, Kevin R. Coombes wrote: >> Hi Duncan, >> >> I just sent a longer version of this message, but it looks to me like >> the underlying issue is the fact that flexmix and Mercator both define >> and export "show" methods for their S4 classes. What confuses me is >> why the NAMESPACE of a package that is merely Suggest'ed by something >> several layers down the hierarchy should get attached and cause an >> issue like this one. (The attached NAMESPACE happens in current >> versions of R.) >> >> Thanks, >>Kevin >> >> On 11/11/2020 1:07 PM, Duncan Murdoch wrote: >>> Okay, I've tried testing on my Mac with R 4.0.3 and R-devel for the >>> new one, 4.0.3 for the CRAN version. >>> >>> I'm not seeing any check error with the CRAN version. I get an error >>> trying to check 0.11.4 from R-forge because I don't have flexmix >>> installed. If I take flexmix out of the Suggests list, it checks >>> with no error on 4.0.3, but I get the error you saw on R-devel when >>> checked with --as-cran. >>> >>> I tried debugging this, and narrowed it down a bit. It happens when >>> your package is installed, in particular in the do_install_source() >>> function in src/library/tools/R/install.R. But that function runs a >>> new R instance, and I didn't get to debugging that. I'll try again >>> later today if nobody else figures it out. >>> >>> Duncan Murdoch >>> >>> >>> >>> >>> On 11/11/2020 12:03 p.m., Kevin R. Coombes wrote: >>>> Hi Duncan, >>>> >>>
Re: [R-pkg-devel] Strange error from CRAN on package submission
Hi Duncan, Thanks for the help. For now (since I want my package to get into CRAN so I can resubmit my paper), I'll add the "Import" clause, and write myself a note to try removing it later. Best, Kevin On 11/11/2020 4:44 PM, Duncan Murdoch wrote: Here's what I think is happening. In the movMF:::.onLoad function there's a test whether flexmix is installed. If found, then it is loaded and some methods are set. (I'm not sure what caused flexmix to be installed: I didn't intentionally install it, but it ended up in there when I installed enough stuff to check Mercator.) In the R-devel --as-cran checks, some checks are run with only strong dependencies of your package visible. Somehow I think that .onLoad function sees flexmix and loads it, but then some other part of the check can't see it. A workaround is to add flexmix to your Imports clause. This is a strong enough dependency to make it visible, and the error goes away. HOWEVER, to me this is pretty clearly an R-devel bug: you have no control over methods set by packages that you don't even use, so you shouldn't have to change your dependency lists if one of them sets a method that you're using. Duncan Murdoch On 11/11/2020 3:31 p.m., Kevin R. Coombes wrote: Oh, I forgot to mention explicitly that checking (with --as-cran) on the development version of R on Windows also produces no errors or warnings. On 11/11/2020 1:39 PM, Kevin R. Coombes wrote: Hi Duncan, I just sent a longer version of this message, but it looks to me like the underlying issue is the fact that flexmix and Mercator both define and export "show" methods for their S4 classes. What confuses me is why the NAMESPACE of a package that is merely Suggest'ed by something several layers down the hierarchy should get attached and cause an issue like this one. (The attached NAMESPACE happens in current versions of R.) Thanks, Kevin On 11/11/2020 1:07 PM, Duncan Murdoch wrote: Okay, I've tried testing on my Mac with R 4.0.3 and R-devel for the new one, 4.0.3 for the CRAN version. I'm not seeing any check error with the CRAN version. I get an error trying to check 0.11.4 from R-forge because I don't have flexmix installed. If I take flexmix out of the Suggests list, it checks with no error on 4.0.3, but I get the error you saw on R-devel when checked with --as-cran. I tried debugging this, and narrowed it down a bit. It happens when your package is installed, in particular in the do_install_source() function in src/library/tools/R/install.R. But that function runs a new R instance, and I didn't get to debugging that. I'll try again later today if nobody else figures it out. Duncan Murdoch On 11/11/2020 12:03 p.m., Kevin R. Coombes wrote: Hi Duncan, Oops; I didn't realize I had forgotten to push updates to the OOMPA web site. The code for Mercator is contained as part of the Thresher project in the subversion repository on R-Forge. (https://r-forge.r-project.org/projects/thresher/) It's under pkg/Mercator below that URL Thanks, Kevin On 11/11/2020 11:30 AM, Duncan Murdoch wrote: Uwe suggested you suggest flexmix, but I see below you already tried that. I'd like to take a look, but I can't find your package. The existing version on CRAN gives the URL as http://oompa.r-forge.r-project.org/, but I can't see it mentioned there. Duncan Murdoch On 11/11/2020 8:44 a.m., Kevin R. Coombes wrote: Hi, I am trying to figure out how to fix warnings from two of the CRAN machines on the submission of an update to a package. The only change to my package was to add a "show" method to one of the S4 classes, which was requested by a reviewer of the paper we submitted. The inability to get this updated package into CRAN is the only thing holding up the revision (and probable acceptance) of the manuscript. The same "warnings"s were found in the previous version. The package is called Mercator, and the CRAN check results from the last version are here: https://cran.r-project.org/web/checks/check_results_Mercator.html I get warnings from the two fedora machine instances (clang and gcc). They both report Check: whether package can be installed. Result: WARN Found the following significant warnings: Warning: namespace ‘flexmix’ is not available and has been replaced > > Check: data for non-ASCII characters Result: WARN Warning: namespace 'flexmix' is not available and has been replaced by .GlobalEnv when processing object '' The relationships in the DESCRIPTION files are: 1. Mercator depends on Thresher 2. Thresher imports moVMF 3. moMVF suggests flexmix On my Windows machine, the package builds and installs with no errors or warnings even if flexmix is not available (which I believe to be the correct behavior). On R-Forge, both the Windows and LINUX versions build and install with no errors or warnings. On R-Hub, tested on
Re: [R-pkg-devel] Strange error from CRAN on package submission
Oh, I forgot to mention explicitly that checking (with --as-cran) on the development version of R on Windows also produces no errors or warnings. On 11/11/2020 1:39 PM, Kevin R. Coombes wrote: Hi Duncan, I just sent a longer version of this message, but it looks to me like the underlying issue is the fact that flexmix and Mercator both define and export "show" methods for their S4 classes. What confuses me is why the NAMESPACE of a package that is merely Suggest'ed by something several layers down the hierarchy should get attached and cause an issue like this one. (The attached NAMESPACE happens in current versions of R.) Thanks, Kevin On 11/11/2020 1:07 PM, Duncan Murdoch wrote: Okay, I've tried testing on my Mac with R 4.0.3 and R-devel for the new one, 4.0.3 for the CRAN version. I'm not seeing any check error with the CRAN version. I get an error trying to check 0.11.4 from R-forge because I don't have flexmix installed. If I take flexmix out of the Suggests list, it checks with no error on 4.0.3, but I get the error you saw on R-devel when checked with --as-cran. I tried debugging this, and narrowed it down a bit. It happens when your package is installed, in particular in the do_install_source() function in src/library/tools/R/install.R. But that function runs a new R instance, and I didn't get to debugging that. I'll try again later today if nobody else figures it out. Duncan Murdoch On 11/11/2020 12:03 p.m., Kevin R. Coombes wrote: Hi Duncan, Oops; I didn't realize I had forgotten to push updates to the OOMPA web site. The code for Mercator is contained as part of the Thresher project in the subversion repository on R-Forge. (https://r-forge.r-project.org/projects/thresher/) It's under pkg/Mercator below that URL Thanks, Kevin On 11/11/2020 11:30 AM, Duncan Murdoch wrote: Uwe suggested you suggest flexmix, but I see below you already tried that. I'd like to take a look, but I can't find your package. The existing version on CRAN gives the URL as http://oompa.r-forge.r-project.org/, but I can't see it mentioned there. Duncan Murdoch On 11/11/2020 8:44 a.m., Kevin R. Coombes wrote: Hi, I am trying to figure out how to fix warnings from two of the CRAN machines on the submission of an update to a package. The only change to my package was to add a "show" method to one of the S4 classes, which was requested by a reviewer of the paper we submitted. The inability to get this updated package into CRAN is the only thing holding up the revision (and probable acceptance) of the manuscript. The same "warnings"s were found in the previous version. The package is called Mercator, and the CRAN check results from the last version are here: https://cran.r-project.org/web/checks/check_results_Mercator.html I get warnings from the two fedora machine instances (clang and gcc). They both report Check: whether package can be installed. Result: WARN Found the following significant warnings: Warning: namespace ‘flexmix’ is not available and has been replaced > > Check: data for non-ASCII characters Result: WARN Warning: namespace 'flexmix' is not available and has been replaced by .GlobalEnv when processing object '' The relationships in the DESCRIPTION files are: 1. Mercator depends on Thresher 2. Thresher imports moVMF 3. moMVF suggests flexmix On my Windows machine, the package builds and installs with no errors or warnings even if flexmix is not available (which I believe to be the correct behavior). On R-Forge, both the Windows and LINUX versions build and install with no errors or warnings. On R-Hub, tested on multiple LINUX versions, the package builds and installs with no errors or warnings. And flexmix is still clearly available from CRAN: https://cran.r-project.org/web/packages/flexmix/index.html In the latest attempt to get things to work, I added Suggests: flexmix into the DESCRIPTION file for Mercator, but this didn't help fix the problem on CRAN. Is there anything I can do to fix this problem (other than moan here on this list and hope that CRAN can just install flexmix on those machines)? Thanks in advance for your help, Kevin [[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
Re: [R-pkg-devel] Strange error from CRAN on package submission
Hi Duncan, I just sent a longer version of this message, but it looks to me like the underlying issue is the fact that flexmix and Mercator both define and export "show" methods for their S4 classes. What confuses me is why the NAMESPACE of a package that is merely Suggest'ed by something several layers down the hierarchy should get attached and cause an issue like this one. (The attached NAMESPACE happens in current versions of R.) Thanks, Kevin On 11/11/2020 1:07 PM, Duncan Murdoch wrote: Okay, I've tried testing on my Mac with R 4.0.3 and R-devel for the new one, 4.0.3 for the CRAN version. I'm not seeing any check error with the CRAN version. I get an error trying to check 0.11.4 from R-forge because I don't have flexmix installed. If I take flexmix out of the Suggests list, it checks with no error on 4.0.3, but I get the error you saw on R-devel when checked with --as-cran. I tried debugging this, and narrowed it down a bit. It happens when your package is installed, in particular in the do_install_source() function in src/library/tools/R/install.R. But that function runs a new R instance, and I didn't get to debugging that. I'll try again later today if nobody else figures it out. Duncan Murdoch On 11/11/2020 12:03 p.m., Kevin R. Coombes wrote: Hi Duncan, Oops; I didn't realize I had forgotten to push updates to the OOMPA web site. The code for Mercator is contained as part of the Thresher project in the subversion repository on R-Forge. (https://r-forge.r-project.org/projects/thresher/) It's under pkg/Mercator below that URL Thanks, Kevin On 11/11/2020 11:30 AM, Duncan Murdoch wrote: Uwe suggested you suggest flexmix, but I see below you already tried that. I'd like to take a look, but I can't find your package. The existing version on CRAN gives the URL as http://oompa.r-forge.r-project.org/, but I can't see it mentioned there. Duncan Murdoch On 11/11/2020 8:44 a.m., Kevin R. Coombes wrote: Hi, I am trying to figure out how to fix warnings from two of the CRAN machines on the submission of an update to a package. The only change to my package was to add a "show" method to one of the S4 classes, which was requested by a reviewer of the paper we submitted. The inability to get this updated package into CRAN is the only thing holding up the revision (and probable acceptance) of the manuscript. The same "warnings"s were found in the previous version. The package is called Mercator, and the CRAN check results from the last version are here: https://cran.r-project.org/web/checks/check_results_Mercator.html I get warnings from the two fedora machine instances (clang and gcc). They both report Check: whether package can be installed. Result: WARN Found the following significant warnings: Warning: namespace ‘flexmix’ is not available and has been replaced > > Check: data for non-ASCII characters Result: WARN Warning: namespace 'flexmix' is not available and has been replaced by .GlobalEnv when processing object '' The relationships in the DESCRIPTION files are: 1. Mercator depends on Thresher 2. Thresher imports moVMF 3. moMVF suggests flexmix On my Windows machine, the package builds and installs with no errors or warnings even if flexmix is not available (which I believe to be the correct behavior). On R-Forge, both the Windows and LINUX versions build and install with no errors or warnings. On R-Hub, tested on multiple LINUX versions, the package builds and installs with no errors or warnings. And flexmix is still clearly available from CRAN: https://cran.r-project.org/web/packages/flexmix/index.html In the latest attempt to get things to work, I added Suggests: flexmix into the DESCRIPTION file for Mercator, but this didn't help fix the problem on CRAN. Is there anything I can do to fix this problem (other than moan here on this list and hope that CRAN can just install flexmix on those machines)? Thanks in advance for your help, Kevin [[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
Re: [R-pkg-devel] Strange error from CRAN on package submission
HI Uwe,
That might be the key observation. The change to Mercator in this
package was to add a "show" method to an S4 class. In its NAMESPACE, the
flexmix package also exports a "show" method.
Both "flexmix" and "Mercator" have an
import("methods")
directive in their NAMESPACE files, which is where the base method for
"show" comes from. Also, if you just type show at the command prompt to
see the definition, you get the parenthetical note that
"(This generic function excludes non-simple inheritance' see ?setIs.)"
I don't completely understand what this parenthetical remark means, but
I have a suspicion that it is highly relevant to my problem.
If I run
library("Mercator")
showMethods("show")
on a system where flexmix is installed, then the "show" method for
flexmix (and related objects) is listed, because the flexmix NAMESPACE
has been attached. If I run the same code on an R system where flexmix
is not installed, then, of course, neither the NAMESPACE nor the method
is available.
I suspect (but am by no means certain) that the combination of that
parenthetical remark above and the existence of the "show" method in the
suggested package is why I am getting errors on some systems.
But I don't really understand why. My package doesn't need the flexmix
version of show. And (as Uwe said in an earlier comment), I thought that
"Suggests" isn't supposed to be inherited. I don't want the flexmix
NAMESPACE attached, since nothing in my package nor in the packages I
directly want (Thresher by "Depends" and then moVMF by "Imports")
actually requires it.
Why does the flexmix NAMESPACE get attached if some other package down
the line merely suggests it? Is that supposed to happen? To me, it feels
like a bug in the sense that it surprises the user (i.e., the package
developer). And I guess is potentially a bug for the ultimate user of
the package, since it adds a NAMESPACE that was not specifically
requested by the top level package being loaded.
In any event, what's the best advice now on how to proceed?
Thanks again,
Kevin
On 11/11/2020 11:34 AM, Uwe Ligges wrote:
Next guess is that you need more, because you may have an object that
needs the flexmix, so likely something S4 related? I can take a closer
look.
Best,
Uwe Ligges
On 11.11.2020 17:30, Duncan Murdoch wrote:
Uwe suggested you suggest flexmix, but I see below you already tried
that.
I'd like to take a look, but I can't find your package. The existing
version on CRAN gives the URL as http://oompa.r-forge.r-project.org/,
but I can't see it mentioned there.
Duncan Murdoch
On 11/11/2020 8:44 a.m., Kevin R. Coombes wrote:
Hi,
I am trying to figure out how to fix warnings from two of the CRAN
machines on the submission of an update to a package. The only
change to
my package was to add a "show" method to one of the S4 classes, which
was requested by a reviewer of the paper we submitted. The inability to
get this updated package into CRAN is the only thing holding up the
revision (and probable acceptance) of the manuscript.
The same "warnings"s were found in the previous version. The package is
called Mercator, and the CRAN check results from the last version
are here:
https://cran.r-project.org/web/checks/check_results_Mercator.html
I get warnings from the two fedora machine instances (clang and gcc).
They both report
Check: whether package can be installed.
Result: WARN
Found the following significant warnings:
Warning: namespace ‘flexmix’ is not available and has been
replaced
>
> Check: data for non-ASCII characters
Result: WARN
Warning: namespace 'flexmix' is not available and has been
replaced
by .GlobalEnv when processing object ''
The relationships in the DESCRIPTION files are:
1. Mercator depends on Thresher
2. Thresher imports moVMF
3. moMVF suggests flexmix
On my Windows machine, the package builds and installs with no
errors or
warnings even if flexmix is not available (which I believe to be the
correct behavior). On R-Forge, both the Windows and LINUX versions
build
and install with no errors or warnings. On R-Hub, tested on multiple
LINUX versions, the package builds and installs with no errors or
warnings.
And flexmix is still clearly available from CRAN:
https://cran.r-project.org/web/packages/flexmix/index.html
In the latest attempt to get things to work, I added
Suggests: flexmix
into the DESCRIPTION file for Mercator, but this didn't help fix the
problem on CRAN.
Is there anything I can do to fix this problem (other than moan here on
this list and hope that CRAN can just install flexmix on those
machines)?
Thanks in advance for your help,
Kevin
[[alternative HTML version deleted]]
__
R-package-
Re: [R-pkg-devel] Strange error from CRAN on package submission
Hi Duncan, Oops; I didn't realize I had forgotten to push updates to the OOMPA web site. The code for Mercator is contained as part of the Thresher project in the subversion repository on R-Forge. (https://r-forge.r-project.org/projects/thresher/) It's under pkg/Mercator below that URL Thanks, Kevin On 11/11/2020 11:30 AM, Duncan Murdoch wrote: Uwe suggested you suggest flexmix, but I see below you already tried that. I'd like to take a look, but I can't find your package. The existing version on CRAN gives the URL as http://oompa.r-forge.r-project.org/, but I can't see it mentioned there. Duncan Murdoch On 11/11/2020 8:44 a.m., Kevin R. Coombes wrote: Hi, I am trying to figure out how to fix warnings from two of the CRAN machines on the submission of an update to a package. The only change to my package was to add a "show" method to one of the S4 classes, which was requested by a reviewer of the paper we submitted. The inability to get this updated package into CRAN is the only thing holding up the revision (and probable acceptance) of the manuscript. The same "warnings"s were found in the previous version. The package is called Mercator, and the CRAN check results from the last version are here: https://cran.r-project.org/web/checks/check_results_Mercator.html I get warnings from the two fedora machine instances (clang and gcc). They both report Check: whether package can be installed. Result: WARN Found the following significant warnings: Warning: namespace ‘flexmix’ is not available and has been replaced > > Check: data for non-ASCII characters Result: WARN Warning: namespace 'flexmix' is not available and has been replaced by .GlobalEnv when processing object '' The relationships in the DESCRIPTION files are: 1. Mercator depends on Thresher 2. Thresher imports moVMF 3. moMVF suggests flexmix On my Windows machine, the package builds and installs with no errors or warnings even if flexmix is not available (which I believe to be the correct behavior). On R-Forge, both the Windows and LINUX versions build and install with no errors or warnings. On R-Hub, tested on multiple LINUX versions, the package builds and installs with no errors or warnings. And flexmix is still clearly available from CRAN: https://cran.r-project.org/web/packages/flexmix/index.html In the latest attempt to get things to work, I added Suggests: flexmix into the DESCRIPTION file for Mercator, but this didn't help fix the problem on CRAN. Is there anything I can do to fix this problem (other than moan here on this list and hope that CRAN can just install flexmix on those machines)? Thanks in advance for your help, Kevin [[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
Re: [R-pkg-devel] Strange error from CRAN on package submission
Hi Uwe, Thanks for the suggestion. I thought of that idea last night, and tried it with the latest submission of version 0.11.4 of Mercator. That version is still in the submission queue waiting for manual inspection, but it gave the same error message. (See https://win-builder.r-project.org/incoming_pretest/Mercator_0.11.4_2020_014655/Debian/00check.log) I think I may try to "Import" or "Depend" on flexmix to force it to be available. Is there some reason why my program should even need to know that flexmix is suggested several layers down the dependency hierarchy? For building and installing the package (or running R CMD check ---as-cran), I tried on my machine when flexmix is not even installed, and got no errors or warnings. There is clearly something I don't understand about namespaces, and I'd like to learn it to avoid this kind of situation in the future. Best, Kevin On 11/11/2020 11:14 AM, Uwe Ligges wrote: You have to suggest flexmix. Best, Uwe Ligges On 11.11.2020 14:44, Kevin R. Coombes wrote: Hi, I am trying to figure out how to fix warnings from two of the CRAN machines on the submission of an update to a package. The only change to my package was to add a "show" method to one of the S4 classes, which was requested by a reviewer of the paper we submitted. The inability to get this updated package into CRAN is the only thing holding up the revision (and probable acceptance) of the manuscript. The same "warnings"s were found in the previous version. The package is called Mercator, and the CRAN check results from the last version are here: https://cran.r-project.org/web/checks/check_results_Mercator.html I get warnings from the two fedora machine instances (clang and gcc). They both report Check: whether package can be installed. Result: WARN Found the following significant warnings: Warning: namespace ‘flexmix’ is not available and has been replaced > > Check: data for non-ASCII characters Result: WARN Warning: namespace 'flexmix' is not available and has been replaced by .GlobalEnv when processing object '' The relationships in the DESCRIPTION files are: 1. Mercator depends on Thresher 2. Thresher imports moVMF 3. moMVF suggests flexmix On my Windows machine, the package builds and installs with no errors or warnings even if flexmix is not available (which I believe to be the correct behavior). On R-Forge, both the Windows and LINUX versions build and install with no errors or warnings. On R-Hub, tested on multiple LINUX versions, the package builds and installs with no errors or warnings. And flexmix is still clearly available from CRAN: https://cran.r-project.org/web/packages/flexmix/index.html In the latest attempt to get things to work, I added Suggests: flexmix into the DESCRIPTION file for Mercator, but this didn't help fix the problem on CRAN. Is there anything I can do to fix this problem (other than moan here on this list and hope that CRAN can just install flexmix on those machines)? Thanks in advance for your help, Kevin [[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-pkg-devel] Strange error from CRAN on package submission
Hi, I am trying to figure out how to fix warnings from two of the CRAN machines on the submission of an update to a package. The only change to my package was to add a "show" method to one of the S4 classes, which was requested by a reviewer of the paper we submitted. The inability to get this updated package into CRAN is the only thing holding up the revision (and probable acceptance) of the manuscript. The same "warnings"s were found in the previous version. The package is called Mercator, and the CRAN check results from the last version are here: https://cran.r-project.org/web/checks/check_results_Mercator.html I get warnings from the two fedora machine instances (clang and gcc). They both report > Check: whether package can be installed. > Result: WARN > Found the following significant warnings: > Warning: namespace ‘flexmix’ is not available and has been replaced > > Check: data for non-ASCII characters > Result: WARN > Warning: namespace 'flexmix' is not available and has been replaced > by .GlobalEnv when processing object '' The relationships in the DESCRIPTION files are: 1. Mercator depends on Thresher 2. Thresher imports moVMF 3. moMVF suggests flexmix On my Windows machine, the package builds and installs with no errors or warnings even if flexmix is not available (which I believe to be the correct behavior). On R-Forge, both the Windows and LINUX versions build and install with no errors or warnings. On R-Hub, tested on multiple LINUX versions, the package builds and installs with no errors or warnings. And flexmix is still clearly available from CRAN: https://cran.r-project.org/web/packages/flexmix/index.html In the latest attempt to get things to work, I added Suggests: flexmix into the DESCRIPTION file for Mercator, but this didn't help fix the problem on CRAN. Is there anything I can do to fix this problem (other than moan here on this list and hope that CRAN can just install flexmix on those machines)? Thanks in advance for your help, Kevin [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Licenses
Hi, I am developing a package and getting a NOTE from R CMD check about licenses and ultimate dependencies on a restrictive license, which I can't figure out how to fix. My package imports flowCore, which has an Artistic-2.0 license. But flowCore imports cytolib, which has a license from the Fred Hutchinson Cancer Center that prohibits commercial use. I tried using the same license as flowCore, but still get the NOTE. Does anyone know which licenses can be used to be compatible with the Fred Hutch license? Or can I just do what flowCore apparently does and ignore the NOTE? Thanks, Kevin __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] DOI for archived package?
Hi, I am in the process of submitting a "workflow" article about an R package (which is onCRAN) to F1000Research. The associate editor that I am dealing with wants a "DOI" for the source code of the package being described in the manuscript. I have already explained that CRAN archives all versions of packages, and I sent him the URL to the archive page for the package, However, he still seems to believe that a DOI needs to be assigned by some site like Zenodo. I haven't yet responded by pointing out that CRAN has been archiving all versions of packages since at least the year 2000, it has mirrors all over the world, and the URL/URI used here is likely to be far more permanent than the DOI from Zenodo. Nor have I pointed out that there are more than 15,000 packages at CRAN, nor that not a single R user would ever think to go look on Zenodo for an R package. Does anyone have other suggestions for how to respond? (I know; I could just put the [expletive] thing into Zenodo and move on, but creating a permanent identifier for something that will *never *be accessed just seems stupid.) Thanks, Kevin [[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
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] [R] a question of etiquette
For academics, aren't those citations the currency in which they are supposed to be paid (at least for R packages)? Kevin On 6/2/2020 3:24 PM, Avraham Adler wrote: On Tue, Jun 2, 2020 at 5:04 PM Spencer Graves < spencer.gra...@effectivedefense.org> wrote: QUESTION: How much money have people on this list received for what they've written? I've received not one penny for any technical article I've written or for software contributed to CRAN. Spencer Ditto. What's even more annoying is when people clearly use one's package in their published work and do not cite it, but that is for a different thread. Avi [[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
