Re: [R-pkg-devel] @doctype is deprecated. need help for r package documentation

[Hadley Wickham]

Do you have a pointer to the roxygen2 comments that you're using?
Hadley

On Thu, Mar 7, 2024 at 5:38 AM Ruff, Sergej 
wrote:

> Hello,
>
> I need help with a package I am currently developing called bootGSEA.
>  I noticed that when I try ‘?bootGSEA’ it goes to the help page in R
> itself but not to the html page (we had this issue last time as well but we
> solved it by adding a documentation to the package itself to the R file)
> like from the before version of the package.
> I tried “_PACKAGE” in the documentation of the package section as @doctype
> is depreceated, but it still doesn’t seem to solve the issue. Do you have
> any idea on this?
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
http://hadley.nz

[[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] how to use pkgdown::build_site() with a project using S7 with a specialized plot()?

[Hadley Wickham]

2.png, reference/figures/force_diagram.R,
> and
> reference/figures/force_diagram.png
> Writing 404.html
> ── Building function reference ──
> ───
> ---
> Backtrace:
> 1. pkgdown::build_site()
> 2. pkgdown:::build_site_external(pkg = pkg, examples = examples,
> run_dont_run = run_don…
> 3. callr::r(function(..., cli_colors, pkgdown_internet) { …
> 4. callr:::get_result(output = out, options)
> 5. callr:::throw(callr_remote_error(remerr, output), parent =
> fix_msg(remerr[[3]]))
> ---
> Subprocess backtrace:
>  1. pkgdown::build_site(...)
>  2. pkgdown:::build_site_local(pkg = pkg, examples = examples,
> run_dont_run = run_dont_r…
>  3. pkgdown::build_reference(pkg, lazy = lazy, examples = examples,
> run_dont_run = run_…
>  4. pkgdown::build_reference_index(pkg)
>  5. pkgdown::render_page(pkg, "reference-index", data =
> data_reference_index(pkg), …
>  6. pkgdown:::render_page_html(pkg, name = name, data = data, depth =
> depth)
>  7. utils::modifyList(data_template(pkg, depth = depth), data)
>  8. base::stopifnot(is.list(x), is.list(val))
>  9. pkgdown:::data_reference_index(pkg)
> 10. meta %>% purrr::imap(data_reference_index_rows, pkg = pkg) %>% …
> 11. base::unlist(., recursive = FALSE)
> 12. purrr::compact(.)
> 13. purrr::discard(.x, function(x) is_empty(.f(x)))
> 14. purrr:::where_if(.x, .p, ...)
> 15. purrr:::map_(.x, .p, ..., .type = "logical", .purrr_error_call =
> .purrr_error_call)
> 16. purrr:::vctrs_vec_compat(.x, .purrr_user_env)
> 17. purrr::imap(., data_reference_index_rows, pkg = pkg)
> 18. purrr::map2(.x, vec_index(.x), .f, ...)
> 19. purrr:::map2_("list", .x, .y, .f, ..., .progress = .progress)
> 20. purrr:::with_indexed_errors(i = i, names = names, error_call =
> .purrr_error_call, …
> 21. base::withCallingHandlers(expr, error = function(cnd) { …
> 22. purrr:::call_with_cleanup(map2_impl, environment(), .type, .progress,
> …
> 23. local .f(.x[[i]], .y[[i]], ...)
> 24. pkgdown:::section_topics(section$contents, pkg$topics, pkg$src_path)
> 25. base::rbind(topics, ext_topics(ext_strings))
> 26. base::rbind(deparse.level, ...)
> 27. pkgdown:::ext_topics(ext_strings)
> 28. purrr::map2(pkg, fun, get_rd_from_help)
> 29. purrr:::map2_("list", .x, .y, .f, ..., .progress = .progress)
> 30. purrr:::with_indexed_errors(i = i, names = names, error_call =
> .purrr_error_call, …
> 31. base::withCallingHandlers(expr, error = function(cnd) { …
> 32. purrr:::call_with_cleanup(map2_impl, environment(), .type, .progress,
> …
> 33. local .f(.x[[i]], .y[[i]], ...)
> 34. rlang::check_installed(package, "as it's used in the reference
> index.")
> 35. base::stop(cnd)
> 36. (function (cnd) …
> 37. cli::cli_abort(message, location = i, name = name, parent = cnd, …
> 38. | rlang::abort(message, ..., call = call, use_cli_format = TRUE, …
> 39. | rlang:::signal_abort(cnd, .file)
> 40. | base::signalCondition(cnd)
> 41. (function (cnd) …
> 42. cli::cli_abort(message, location = i, name = name, parent = cnd, …
> 43. | rlang::abort(message, ..., call = call, use_cli_format = TRUE, …
> 44. | rlang:::signal_abort(cnd, .file)
> 45. | base::signalCondition(cnd)
> 46. global (function (e) …
> Execution halted
>
>
>
> On Jan 3, 2024, at 1:06 PM, Hadley Wickham  wrote:
>
> CAUTION: The Sender of this email is not from within Dalhousie.
> This bug is fixed in the dev version (I don’t remember off the top of my
> head in which of pkgdown and roxygen2 you need but it might be both). I’m
> planning CRAN updates for both in the near future.
>
> Hadley
>
> On Thursday, January 4, 2024, Daniel Kelley  wrote:
>
>> # Question
>>
>> Is there an online example online of specializing `plot()` for S7
>> objects, such that `pkgdown::build_site()` will produce webpages?  I ask
>> because I find lots of users (of other packages) tend to consult websites
>> made with pkgdown, rather than using the online help within R.  I think the
>> problem I am having (discussed in the following sections) has to do with my
>> specialization of plot().  I say that because when I was using S3 objects
>> in an earlier version of my package, `pkgdown::build_site()` worked as
>> intended.
>>
>> # Background
>>
>> In my 'mooring' package (https://github.com/dankelley/mooring/tree/S7),
>> I am writing code like (https://github.com/dankelley/
>> mooring/blob/f70b53ca12e88968f65710c205b50a64f750a99d/R/plot.R#L69)
>>
>> ```R
>> #' @aliases plot.mooring
>> #' ETC
>> `plot.mooring::mooring` <- plot(ETC) ETC
>> ```
>>
>> to handle objects made with (https://github.com/dank

Re: [R-pkg-devel] how to use pkgdown::build_site() with a project using S7 with a specialized plot()?

[Hadley Wickham]

This bug is fixed in the dev version (I don’t remember off the top of my
head in which of pkgdown and roxygen2 you need but it might be both). I’m
planning CRAN updates for both in the near future.

Hadley

On Thursday, January 4, 2024, Daniel Kelley  wrote:

> # Question
>
> Is there an online example online of specializing `plot()` for S7 objects,
> such that `pkgdown::build_site()` will produce webpages?  I ask because I
> find lots of users (of other packages) tend to consult websites made with
> pkgdown, rather than using the online help within R.  I think the problem I
> am having (discussed in the following sections) has to do with my
> specialization of plot().  I say that because when I was using S3 objects
> in an earlier version of my package, `pkgdown::build_site()` worked as
> intended.
>
> # Background
>
> In my 'mooring' package (https://github.com/dankelley/mooring/tree/S7), I
> am writing code like (https://github.com/dankelley/mooring/blob/
> f70b53ca12e88968f65710c205b50a64f750a99d/R/plot.R#L69)
>
> ```R
> #' @aliases plot.mooring
> #' ETC
> `plot.mooring::mooring` <- plot(ETC) ETC
> ```
>
> to handle objects made with (https://github.com/dankelley/mooring/blob/
> f70b53ca12e88968f65710c205b50a64f750a99d/R/oo.R#L2)
>
> ```R
> mooringS7 <- S7::new_class("mooring",
> package = "mooring",
> ETC
> ```
>
> Built up in Rstudio, with Roxygen2 being used to create documentation,
> things seem to work, e.g.
>
> ```R
> m <- mooring(anchor(), wire(length = 80), float(), waterDepth = 100)
> plot(m)
> ```
>
> produces a plot as intended, and
>
> ```R
> ?plot.mooring
> ```
>
> produces documentation as intended.
>
> *However* I encounter a problem comes when I try building a website with
>
> ```R
> pkgdown::build_site()
> ```
>
> This yields results as in the next section.  (I apologize for the length.
> I'm including the whole thing because I thought that would be less
> bothersome than writing another email to the list.)
>
> I am not sure how to find the problem, and so I hope that someone on this
> list can point out an example of how to set up `plot()` to work with S7
> objects, in such a way that documentation can be created with Roxygen2 and
> websites can be made with `pkgdown::build_site()`.
>
> # What pkgdown::build_site() gives
>
> ```
> > library(pkgdown)
> > build_site()
> Warning: Failed to parse usage:
>
> S3method(`plot`, ``mooring::mooring``)(
>   x,
>   which = "shape",
>   showInterfaces = TRUE,
>   showDepths = FALSE,
>   showLabels = TRUE,
>   showDetails = FALSE,
>   fancy = FALSE,
>   title = "",
>   mar = c(1.5, 3.5, 3.5, 1),
>   mgp = c(2, 0.7, 0),
>   xlim = NULL,
>   xaxs = "r",
>   yaxs = "r",
>   type = "l",
>   debug = 0,
>   ...
> )
>
> -- Installing package into temporary library 
> == Building pkgdown site ==
> =
> Reading from: '/Users/kelley/git/mooring'
> Writing to:   '/Users/kelley/git/mooring/docs'
> -- Initialising site --
> -
> -- Building home --
> -
> Writing '404.html'
> -- Building function reference --
> ---
> Error:
> ! in callr subprocess.
> Caused by error in `map2(.x, vec_index(.x), .f, ...)`:
> ! In index: 1.
> ℹ See `$stdout` for standard output.
> Type .Last.error to see the more details.
> > .Last.error
> 
> Error:
> ! in callr subprocess.
> Caused by error in `map2(.x, vec_index(.x), .f, ...)`:
> ! In index: 1.
> ℹ See `$stdout` for standard output.
> ---
> Backtrace:
> 1. pkgdown::build_site()
> 2. pkgdown:::build_site_external(pkg = pkg, examples = examples, run…
> 3. callr::r(function(..., cli_colors, pkgdown_internet) { …
> 4. callr:::get_result(output = out, options)
> 5. callr:::throw(callr_remote_error(remerr, output), parent = fix_…
> ---
> Subprocess backtrace:
>  1. pkgdown::build_site(...)
>  2. pkgdown:::build_site_local(pkg = pkg, examples = examples, run_do…
>  3. pkgdown::build_reference(pkg, lazy = lazy, examples = examples, …
>  4. pkgdown::build_reference_index(pkg)
>  5. pkgdown::render_page(pkg, "reference-index", data = data_referen…
>  6. pkgdown:::render_page_html(pkg, name = name, data = data, depth =…
>  7. utils::modifyList(data_template(pkg, depth = depth), da…
>  8. base::stopifnot(is.list(x), is.list(val))
>  9. pkgdown:::data_reference_index(pkg)
> 10. meta %>% purrr::imap(data_reference_index_rows, pkg = p…
> 11. base::unlist(., recursive = FALSE)
> 12. purrr::compact(.)
> 13. purrr::discard(.x, function(x) is_empty(.f(x)))
> 14. purrr:::where_if(.x, .p, ...)
> 15. purrr:::map_(.x, .p, ..., .type = "logical", .purrr_error_call …
> 16. purrr:::vctrs_vec_compat(.x, .purrr_user_env)
> 17. purrr::imap(., data_reference_index_rows, pkg = pkg)
> 18. purrr::map2(.x, vec_index(.x), .f, ...)
> 19. purrr:::map2_("list", .x, .y, .f, ..., .progress = .progress)
> 20. purrr:::with_indexed_errors(i = i, 

Re: [R-pkg-devel] Discrepancy between R CMD check results and usethis::use_cran_comments

[Hadley Wickham]

On Tue, Sep 26, 2023 at 2:01 AM Leonard Mada via R-package-devel
 wrote:
>
> Dear List-Members,
>
> There are no errors/warnings/notes when I run the check:
>
> ── R CMD check results
>  Rpdb 2.3.3 
> Duration: 2m 50.1s
>
> 0 errors ✔ | 0 warnings ✔ | 0 notes ✔
>
> However, there is a discrepancy when I run:
> usethis::use_cran_comments(open = rlang::is_interactive())
> =>
> 0 errors ✔ | 0 warnings ✔ | 1 note
>
> For some reason, the file is saved with 1 note. The discrepancy remains
> even if I restart R, delete the old cran-comments.md file, and re-run
> the check.

This is just a template; you need to fill it out with the actual
results. (There's usually one note on first submission which is why we
use this as the default.)

Hadley

-- 
http://hadley.nz
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] How to fix Archived Package Rpdb?

[Hadley Wickham]

On Fri, Sep 8, 2023 at 6:02 AM Leonard Mada via R-package-devel
 wrote:
>
> Dear Members,
>
> I would like to reanimate the archived package Rpdb:
> https://cran.r-project.org/web/packages/Rpdb/index.html
>
> 1.) I have tried to contact the original author by email, but got no
> response.
>
> 2.) New Repository on GitHub
> I have copied the existing code to a new repository on GitHub:
> https://github.com/discoleo/Rpdb
>
> - fixed the use of deprecated functions (rgl);
> - fixed some bug with Roxygen2;
> - I hope that all errors are now fixed;
>
> 2.b.) Description file
> - I left the original author as the author (with the provided e-mail
> address): should I delete this email?

It probably doesn't matter than much either way, but since the author
doesn't appear to respond to emails to that address, I personally
would lean towards deleting it.

> - I have added myself as maintainer;
> - I have increased the last digit of the version number;
> - I have added links to this new GitHub repository: I did not find any
> other links in the previous version (except to the pdb-format);
> - updated the licence to GPL v3: the original does not specify any
> version number;
>
>
> Is there anything else that needs to be done?

There are at least three 3 R CMD check failures you need to address:

* The Authors@R field in DESCRIPTION is incorrectly formed, you need
something like this:
c(
  person("Leonard", "Mada", email = "leo.m...@syonic.eu", role = c("cre")),
  person("Julien", "Idé", role = c("aut"))
)

* You need to add LICENSE to .Rbuildignore, or and IMO better, delete
that file and use usethis::use_gpl3_license() to the license in
markdown form, and correctly ignored for CRAN submission

* Many examples use `\%in\%` instead of `%in%.

To make these sorts of problems easier to spot in the future I'd
suggest setting up a GitHub action to automatically run R CMD check
every time you push to GitHub. One easy way to do that is to run
usethis::use_github_action("check-standard").

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] LICENSE file in an R package for CRAN submission

[Hadley Wickham]

If you're using one of the licenses supported by usethis
(https://usethis.r-lib.org/reference/licenses.html), you can just call
the appropriate function and it will do all the setup required to be
both CRAN and GitHub compatible.

Hadley

On Wed, Aug 9, 2023 at 10:10 AM Emanuele Cordano
 wrote:
>
> Dear list,
>
> is there a way to put the LICENSE file within an R package like in Github,
> I have an R package on Github with a a LICENSE file compliant to Github and
> containing the text of the licence citing in the DESCRIPION file. But when
> I check the package , I obatained the following output:
>
> * checking top-level files ... NOTE
> File
>   LICENSE
>
> is not mentioned in the DESCRIPTION file.
>
> How can I solve this?
> Thank you
> best
> Emanuele Cordano
> --
> Emanuele Cordano, PhD
> Environmental Engineer / Ingegnere per l' Ambiente e il territorio nr.
> 3587 (Albo A - Provincia di Trento)
> cell: +39 3282818564
> email: emanuele.cord...@gmail.com,emanuele.cord...@rendena100.eu,
> emanuele.cord...@eurac.edu
> PEC: emanuele.cord...@ingpec.eu
> URL: www.rendena100.eu
> LinkedIn: https://www.linkedin.com/in/emanuele-cordano-31995333
> GitHub: https://github.com/ecor
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Feedback on "Using Rust in CRAN packages"

[Hadley Wickham]

> > If CRAN cannot trust even the official one of Rust, why does CRAN have Rust 
> > at all?
> >
>
> I don't see the connection - if you downloaded something in the past it 
> doesn't mean you will be able to do so in the future. And CRAN has Rust 
> because it sounded like a good idea to allow packages to use it, but I can 
> see that it opened a can of worms that we trying to tame here.

Can you give a bit more detail about your concerns here? Obviously
crates.io isn't some random site on the internet, it's the official
repository of the Rust language, supported by the corresponding
foundation for the language. To me that makes it feel very much like
CRAN, where we can assume if you downloaded something in the past, you
can download something in the future.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Unfortunate function name generic.something

[Hadley Wickham]

If it's internal only, you could change the name to levels_no()?
Hadley

On Mon, May 8, 2023 at 7:28 AM Ulrike Groemping
 wrote:
>
> Thanks, Duncan. I appreciate the view that levels.no acts as an S3
> method for the generic levels, if an object of class "no" is handed to
> it. However, as the function is not intended as an S3 method, it does
> not make sense to document it as such. As the function is internal only,
> which makes the scenario that it causes trouble extremely unlikely, I
> will simply comment out the usage line for the function in order to get
> rid of the note but keep the usage visible. I hope that this is OK.
>
> Best, Ulrike
>
> Am 08.05.2023 um 13:58 schrieb Duncan Murdoch:
> > There really isn't such a thing as "a function that looks like an S3
> > method, but isn't".  If it looks like an S3 method, then in the proper
> > circumstances, it will be called as one.
> >
> > In your case the function name is levels.no, and it isn't exported.
> > So if you happen to have an object with a class inheriting from "no",
> > and you call levels() on it, levels.no might be called.
> >
> > This will only affect users of your package indirectly.  If they have
> > objects inheriting from "no" and call levels() on them, levels.no will
> > not be called.  But if they pass such an object to one of your package
> > functions, and that function calls levels() on it, they could end up
> > calling levels.no().  It all depends on what other classes that object
> > inherits from.
> >
> > You can test this yourself.  Set debugging on any one of your
> > functions, then call it in the normal way.  Then while still in the
> > debugger set debugging on levels.no, and create an object using
> >
> >   x <- structure(1, class = "no")
> >
> > and call levels(x).  You should break to the code of levels.no.
> >
> > That is why the WRE manual says "First, a caveat: a function named
> > gen.cl will be invoked by the generic gen for class cl, so do not name
> > functions in this style unless they are intended to be methods."
> >
> > So probably the best solution (even if inconvenient) is to rename
> > levels.no to something that doesn't look like an S3 method.
> >
> > Duncan Murdoch
> >
> > On 08/05/2023 5:50 a.m., Ulrike Groemping wrote:
> >> Thank your for the solution attempt. However, using the keyword internal
> >> does not solve the problem, the note is still there. Any other proposals
> >> for properly documenting a function that looks like an S3 method, but
> >> isn't?
> >>
> >> Best, Ulrike
> >>
> >> Am 05.05.2023 um 12:56 schrieb Iris Simmons:
> >>> You can add
> >>>
> >>> \keyword{internal}
> >>>
> >>> to the Rd file. Your documentation won't show up the in the pdf
> >>> manual, it won't show up in the package index, but you'll still be
> >>> able to access the doc page with ?levels.no  or
> >>> help("levels.no ").
> >>>
> >>> This is usually used in a package's deprecated and defunct doc pages,
> >>> but you can use it anywhere.
> >>>
> >>> On Fri, May 5, 2023, 06:49 Ulrike Groemping
> >>>  wrote:
> >>>
> >>>  Dear package developeRs,
> >>>
> >>>  I am working on fixing some notes regarding package DoE.base.
> >>>  One note refers to the function levels.no  and
> >>>  complains that the
> >>>  function is not documented as a method for the generic function
> >>>  levels.
> >>>  Actually, it is not a method for the generic levels, but a
> >>> standalone
> >>>  internal function that I like to have documented.
> >>>
> >>>  Is there a way to document the function without renaming it and
> >>>  without
> >>>  triggering a note about method documentation?
> >>>
> >>>  Best, Ulrike
> >>>
> >>>  --
> >>>  ##
> >>>  ## Prof. Ulrike Groemping
> >>>  ## FB II
> >>>  ## Berliner Hochschule für Technik (BHT)
> >>>  ##
> >>>  ## prof.bht-berlin.de/groemping
> >>> 
> >>>  ## Phone: +49(0)30 4504 5127
> >>>  ## Fax:   +49(0)30 4504 66 5127
> >>>  ## Home office: +49(0)30 394 04 863
> >>>  ##
> >>>
> >>>  __
> >>>  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



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Acknowledging small functions from another package

[Hadley Wickham]

IMO those functions are so small that you don't need to call them out
in your DESCRIPTION. Just note in a nearby comment where they came
from.

Hadley

On Thu, May 4, 2023 at 3:21 AM David Hugh-Jones
 wrote:
>
> Hi,
>
> One of my packages copy-pasted some small functions (stuff like `%||%` for
> is.null) from ggplot2. (Both packages are MIT-licensed.)
>
> What is an appropriate way to acknowledge this in the DESCRIPTION Author:
> or Authors@R section? (Note that the list of ggplot2 authors is long and
> changing.)
>
> Cheers,
> David
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Changing R Package Maintainer

[Hadley Wickham]

Just submit your package, and you'll get an automated email to the old address.

Hadley

On Sat, Apr 8, 2023 at 7:14 AM Andrew Simmons  wrote:
>
> Hi,
>
>
> I'm changing my name and my email address. I've got an update I'd like to
> submit to CRAN, I've changed my name and email in my DESCRIPTION.
>
> I couldn't find any details about changing maintainers in the R manuals
> unfortunately. Someone online said to just submit the update, CRAN will
> send one email to the new address confirming the submission, and another to
> the old address confirming the new maintainer. Someone else said to email
> CRAN from the old address about the new maintainer and their address, and
> wait for a response of approval before submission. It was unclear if that
> would be cran-submissi...@r-project.org or c...@r-project.org, but I'd
> guess the first.
>
> Has anyone else done this before or does anyone know the best procedure?
> Also, given that this isn't a transfer of ownership, I'm still the same
> person with a different name, would that make this process easier?
>
>
> Thank you!
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Best way forward on a CRAN archived package

[Hadley Wickham]

I’d suggest resubmitting, after ensuring that R CMD  check runs without any
notes, warnings, or errors.

Hadley

On Monday, October 10, 2022, Diego Hernangómez Herrero <
diego.hernangomezherr...@gmail.com> wrote:

> Hi:
>
> I have some doubts on how to proceed in this case. I am the developer of
> tidyterra, and I received an email from CRAN on 23Sep2022 about an issue on
> the package, setting a deadline on 07Oct2022 to correct it.
>
> I sent a patch that was accepted on CRAN on 29Sep2022, that fixed the issue
> (or at least I am pretty sure I solved it). I received no further feedback
> by CRAN, so I assumed the package was safe. However it was finally archived
> on 07Oct2022.
>
> I have already sent an email to CRAN in order to check if they think the
> issues still persist (or maybe they missed the patch submission?), but I am
> in a rush since there are other packages that depend on tidyterra and they
> may be in risk of being archived on CRAN as well.
>
> So my question is: What is the best way forward at this point? Should I
> wait to get some feedback from CRAN or is it best to resubmit the package
> (I already have a new patch prepared)? I acknowledge that  "The time of the
> volunteers is CRAN’s most precious resource" so my goal is to reduce their
> burden as much as possible.
>
> Kind regards
>
> --
>
>
>
> Have a nice day!
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
http://hadley.nz

[[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] Issue handling datetimes: possible differences between computers

[Hadley Wickham]

On Sun, Oct 9, 2022 at 9:31 PM Jeff Newmiller  wrote:
>
> ... which is why tidyverse functions and Python datetime handling irk me so 
> much.
>
> Is tidyverse time handling intrinsically broken? They have a standard 
> practice of reading time as UTC and then using force_tz to fix the "mistake". 
> Same as Python.

Can you point to any docs that lead you to this conclusion so we can
get them fixed? I strongly encourage people to parse date-times in the
correct time zone; this is why lubridate::ymd_hms() and friends have a
tz argument.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN package isoband and its reverse dependencies

[Hadley Wickham]

Yes, we will make sure that this is fixed ASAP. There is no need to worry.

Hadley

On Wed, Oct 5, 2022 at 7:32 AM John Harrold  wrote:
>
> Howdy Folks,
>
> I got a message from CRAN today telling me that I have a strong reverse
> dependency on the isoband package. But I'm not alone! It look like more
> than 4700 other packages also have a strong dependency on this. Is there
> some organized effort to deal with this?
>
> Thanks
> John
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Non-ASCII and CRAN Checks

[Hadley Wickham]

In my experience this NOTE does not interfere with CRAN submission and you
can ignore it.

Hadley

On Monday, September 19, 2022, Igor L  wrote:

> Hello everybody,
>
> I'm testing my package with the devtools::check() function and I got a
> warning about found non-ASCII strings.
>
> These characters are in a dataframe and, as they are names of institutions
> used to filter databases, it makes no sense to translate them.
>
> Is there any way to make the check accept these characters?
>
> They are in latin1 encoding.
>
> Thanks in advance!
>
> --
> *Igor Laltuf Marques*
> Economist (UFF)
> Master in urban and regional planning (IPPUR-UFRJ)
> Researcher at ETTERN e CiDMob
> https://igorlaltuf.github.io/
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
http://hadley.nz

[[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: What is a "retired"package?

[Hadley Wickham]

Yes, as Lionel said that is why we have changed our terminology to
superseded — we wanted to imply that a retired package was still a
useful member of society, if not working full-time anymore, but most
people seem to think that retired means that we took the package out
behind the shed and put it out of its misery.

Haley

On Tue, Sep 21, 2021 at 1:43 PM Lenth, Russell V
 wrote:
>
> Hadley,
>
> As I suspected, and a good point. But please note that the term "retired" 
> causes angst, and it may be good to change that to "superceded" or something 
> else.
>
> As a side note, I'll mention that I myself am retired, and I'll claim that 
> that does not make me less dependable. But one difference in retirement is 
> that I now care less about public embarrassment, such as not knowing that all 
> along, I could have used base::apply instead of plyr::aaply.
>
> -Original Message-
> From: Hadley Wickham 
> Sent: Tuesday, September 21, 2021 11:48 AM
> To: Lenth, Russell V 
> Cc: Jeff Newmiller ; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] [External] Re: What is a "retired"package?
>
> > But for the broader question, Jeff is saying that there really are 700 
> > packages that are in potential trouble!
>
> I think that's rather an overstatement of the problem — there's nothing wrong 
> with plyr; it's just no longer under active development.
> If anything, plyr is one of the safest packages to depend upon because you 
> can know it will never change :)
>
> Hadley
>
> --
> http://hadley.nz



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [External] Re: What is a "retired"package?

[Hadley Wickham]

> But for the broader question, Jeff is saying that there really are 700 
> packages that are in potential trouble!

I think that's rather an overstatement of the problem — there's
nothing wrong with plyr; it's just no longer under active development.
If anything, plyr is one of the safest packages to depend upon because
you can know it will never change :)

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] best LICENSE practices: AGPL-3 + LaTeX Project Public License

[Hadley Wickham]

On Wed, Jul 14, 2021 at 9:11 AM Ben Bolker  wrote:
>
>
>In the process of trying to get a package to build successfully on
> r-hub's Fedora platform, I had to add a whole bunch of LaTeX .sty files
> to the vignette directory.  One of these was collectbox.sty, which
> triggers the NOTE
>
> ---
> NOTE
> The following files contain a license that requires
> distribution of original sources:
>‘collectbox.sty’
> ---
>
>The licensing/copyright information in collectbox.sty is as follows:
>
>
> %% The original source files were:
> %%
> %% collectbox.dtx  (with options: `collectbox.sty')
> %%
> %% IMPORTANT NOTICE:
> %%
> %% For the copyright see the source file.
> %%
> %% Any modified versions of this file must be renamed
> %% with new filenames distinct from collectbox.sty.
> %%
> %% For distribution of the original source see the terms
> %% for copying and modification in the file collectbox.dtx.
> %%
> %% This generated file may be distributed as long as the
> %% original source files, as listed above, are part of the
> %% same distribution. (The sources need not necessarily be
> %% in the same archive or directory.)
> %% Copyright (C) 2012 by Martin Scharrer 
> %% 
> %% This work may be distributed and/or modified under the
> %% conditions of the LaTeX Project Public License, either version 1.3
> %% of this license or (at your option) any later version.
> %% The latest version of this license is in
> %%   http://www.latex-project.org/lppl.txt
> %% and version 1.3 or later is part of all distributions of LaTeX
> %% version 2005/12/01 or later.
>
> So I put collectbox.dtx into the inst/misc directory in the package.
> Fine.
>
>   Now, what do I need to do to (1) make sure that my DESCRIPTION file is
> correct and (2) hopefully, suppress the NOTE so I don't have to explain
> it to the CRAN maintainers every time?
>
> * Do I change the LICENCE line (which is currently AGPL-3)? According to
> https://cran.r-project.org/doc/manuals/R-exts.html#Licensing it would
> seem I would have to switch to "file LICENCE" (adding a
> "Licence_is_FOSS: yes"), where "LICENCE" contains something like
>
> package code licensed under AGPL-3; file vignettes/collectbox.sty is
> under the LaTeX Project Public License (source provided in
> misc/collectbox.dtx)
>
> ? Should it say "file LICENCE" or "AGPL-3 + file LICENCE" ?
>
> * Do I just include the files without comment, since I have complied (as
> far as I can tell) with the terms of the LPPL?

It's my understanding that the goal of the license field is to list
one license that the entire package can be distributed under (i.e. is
compatible with all licenses in the package). As long as you believe
that LPPL is compatible with the AGPL-3, then it's fine to keep the
license as AGPL-3.

I don't believe it would be correct to use "AGPL-3 + file LICENSE` as
R-exts only lists three uses of file LICENSE, none of which apply to
your case:

> If a package license restricts a base license (where permitted, e.g., using 
> GPL-3 or AGPL-3 with an
> attribution clause), the additional terms should be placed in file LICENSE 
> (or LICENCE), and the
> string ‘+ file LICENSE’ (or ‘+ file LICENCE’, respectively) should be 
> appended to the corresponding
> individual license specification.

> The optional file LICENSE/LICENCE contains a copy of the license of the 
> package...
> Whereas you should feel free to include a license file in your source 
> distribution, please do not arrange to
install yet another copy of the GNU COPYING or COPYING.LIB files ...
> Since files named LICENSE or LICENCE will be installed, do not use these 
> names for standard license files.

> A few “standard” licenses are rather license templates which need additional 
> information to be
> completed via ‘+ file LICENSE’.

I also recommend two additional changes:

* Include a LICENSE.note field that describes any parts of the package
that are available under other licenses.

* Add the authors of the included files to Authors@R

See https://r-pkgs.org/license.html#how-to-include for more details. I
haven't had any explicit feedback on these recommendations from CRAN
but they have worked for me in package submissions and align with my
(possibly flawed) understanding of CRAN policies and beliefs around
licensing.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] winUCRT failures

[Hadley Wickham]

Who is responsible for the winUCRT checks? Perhaps that person could
provide us with a list of root causes behind the testthat failures,
and we could look into resolving them.

Hadley

On Sun, Apr 25, 2021 at 7:50 AM Duncan Murdoch  wrote:
>
> The current CRAN release of rgl fails on winUCRT because of missing
> dependencies:
>
> 'htmlwidgets', 'htmltools', 'knitr', 'jsonlite', 'shiny', 'magrittr',
> 'crosstalk', 'manipulateWidget'.
>
> Tracing `htmlwidgets` shows it also fails because of missing dependencies:
>
> 'htmltools', 'jsonlite', 'yaml'
>
> and 'htmltools' fails because of missing dependencies
>
> 'digest', 'base64enc', 'rlang'
>
> but 'digest' only gets a warning (congratulations, Dirk!), 'base64enc'
> gets a NOTE (hurray Simon!).  'rlang' is failing a test because of a
> missing suggested dependency on 'glue'.  At that point I stopped searching.
>
> Does anyone have a list of packages that actually need fixes?  I'd like
> to help those maintainers with the necessary updates.
>
> Duncan Murdoch
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] winUCRT failures

[Hadley Wickham]

> One additional thought:
>
> If the testing package (i.e. testthat in this case) had been available
> but other suggested packages were not, it would be worth running tests
> with just testthat present:  that might be why you called the decision
> defensible.  I'd agree with that.
>
> However, it's still true that the fact that testthat has to be present
> to make magrittr available is a pretty serious flaw in magrittr and/or
> the CRAN processes.  Hopefully magrittr's authors are less stubborn than
> R Core/CRAN, and will make their package more resilient.

Isn't this a 0/0 problem? If there are zero failures from zero tests,
do we really want to declare that the package is ok?

I'm not interested in participating in another debate about whether or
not one should assume that suggested packages are available when
checking a package. Some time ago, we decided to install all suggested
packages when running reverse dependency checks and it has caused us
few problems (especially since linux binaries for all CRAN packages
are now readily available). Either way, isn't it easier for the
handful of experienced developers who perform many R CMD check runs to
install all suggested packages, rather than trying to get thousands of
individual package maintainers to change their behaviour?

Hadley



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Testing on old R versions

[Hadley Wickham]

On Sun, Jan 31, 2021 at 4:32 AM Duncan Murdoch  wrote:
>
> I am trying out a modified version of the tidyverse actions, and it does
> seem to be going well.  Just one question:
>
> rgl has a soft dependency on alphashape3d, and alphashape3d has a hard
> dependency on rgl.  This means that I need to install in the order
>
>rgl hard dependencies
>rgl
>rgl soft dependencies
>
> Currently I'm using this code to do that:
>
># First install rgl with minimal deps then the rest
>devtools::install()
>remotes::install_deps(dependencies = TRUE)
>
> but devtools seems unnecessarily heavy for this.  Does remotes have a
> way to specify the install in the right order?

I forget all the details here but instead of `devtools::install()`,
I'm pretty sure you can just use `remotes::install_local()`.

We also have an experimental workflow that uses pak
(https://github.com/r-lib/actions/blob/master/examples/check-pak.yaml);
and pak should know enough about the full dependency graph to install
all dependencies in the correct order without additional work. This
workflow (and pak) itself, is still a bit experimental but we've
started to move the tidyverse workflows to use pak, and haven't had
many problems recently.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] best practices for handling a mixed-licensed package

[Hadley Wickham]

This is why I recommend that if you copy an entire directory of code you
include the LICENSE file for that directory; if you copy a single file,
make the license clear at the comment in a top of the file. This is
standard practice in most open source communities.

If you’re writing open source code, I don’t think it’s necessary to retain
a lawyer in order to handle these commonplace issues. (OTOH if you’re
building a business on top of open source code, hiring a lawyer is
absolutely essential).

Hadley

On Saturday, October 3, 2020, Jeff Newmiller 
wrote:

> You are addressing interpretation of "a license", while my concern is not
> with the licenses themselves but with the identification of which code goes
> with which license. Assuming that you will need to retain lawyers to decide
> how to handle a license in a particular use case may be reasonable, but
> assuming you will also use them to parse the files in the package  seems
> rather less reasonable IMO when you have such a clear alternative
> (packaging).
>
> On October 3, 2020 9:02:02 AM PDT, Dirk Eddelbuettel 
> wrote:
> >
> >On 3 October 2020 at 09:54, Hadley Wickham wrote:
> >| I think this is a bit of an oversimplification, especially given that
> >| "compatibility" is not symmetric. For example, you can include MIT
> >license
> >| code in a GPL licensed package; you can not include GPL licensed code
> >| inside an MIT licensed package. There are some rough guidelines at
> >| https://r-pkgs.org/license.html#license-compatibility.
> >
> >One approach for issues such as legal matters is to consult
> >subject-matter
> >experts which is why I pointed (in a prior private message spawned by
> >this
> >same thread) to sites such as
> >
> >  https://tldrlegal.com/
> >  https://choosealicense.com/
> >
> >Dirk
>
> --
> Sent from my phone. Please excuse my brevity.
>


-- 
http://hadley.nz

[[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] best practices for handling a mixed-licensed package

[Hadley Wickham]

On Fri, Oct 2, 2020 at 5:26 PM Dirk Eddelbuettel  wrote:

>
> On 2 October 2020 at 14:44, Jeff Newmiller wrote:
> | if you want clarity in the minds of _users_ I would beg you to split the
> code into two packages. People will likely either be afraid of the GPL
> bogey man and refrain from utilizing your MIT code as permitted or fail to
> honor the GPL terms correctly if both are in the same package.
>
> Have you read R's own doc/COPYRIGHTS ?
>
>https://github.com/wch/r-source/blob/trunk/doc/COPYRIGHTS
>
> In short the opposite of what you just suggest.
>
> Also, labels such as "more liberal" or "permissive" or "bogey man" are not
> exactly unambiguous.  Different people can and do have different views
> here.
> I would suggest using simpler terms such as "different". What matters is
> that
> the licenses permit open source use while ensuring they are compatible
> which
> is generally the case these days.
>

I think this is a bit of an oversimplification, especially given that
"compatibility" is not symmetric. For example, you can include MIT license
code in a GPL licensed package; you can not include GPL licensed code
inside an MIT licensed package. There are some rough guidelines at
https://r-pkgs.org/license.html#license-compatibility.

Hadley

-- 
http://hadley.nz

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] win-builder down?

[Hadley Wickham]

Hi all,

Is win-builder down? I submitted a couple of packages >24 hours ago,
and haven't heard back.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Require -package.Rd?

[Hadley Wickham]

On Tue, Sep 24, 2019 at 8:07 AM Georgi Boshnakov
 wrote:
>
> It is worth noting that
>
> help(package="")
>
> shows  file -package.Rd, while
>
> help()
>
> shows topic "package".
>
> Topic -package.Rd is also printed at the top of the pdf manual, 
> while package.Rd follows the alphabetical ordering of the remaining topics. 
> It is unfortunate that Hadley Wickham's tools (at least 'pkgdown') recommend 
> and use .Rd, instead of -package.Rd as overall package 
> description.

I'm not sure what lead you to that believe, but we definitely support
(and have supported for years) package?.  See, e.g.
https://usethis.r-lib.org/reference/use_package_doc.html

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] OFFICIAL: R-devel check error: package or NAMESPACE load failed, there is no package called broom

[Hadley Wickham]

This works for me locally too, so I'd recommend trying win-devel
again. Sometimes you catch it in an inconsistent state and your check
fails for reasons unrelated to your package.

Hadley

On Sat, Sep 7, 2019 at 3:50 PM Georgina Anderson
 wrote:
>
> OFFICIAL
>
> Hi
>
> Any help with the following update to my package PHEindicatormethods would be 
> appreciated.
>
> I have made a very minor change to the package to fix dependencies on the 
> tidyr:nest() function as tidyr v 1.0.0 is due to be released with breaking 
> changes on 9th September.
> The version I am trying to upload to CRAN is 1.1.5 available here: 
> https://github.com/PublicHealthEngland/PHEindicatormethods
>
>
> When I run devtools::check_win_devel locally (Windows 10 laptop, R 3.6.1, 
> rStudio 1.2.1335) it passes with no NOTES, ERRORS or WARNINGS (locally it 
> also passes devtools::check_win on release and oldrelease and 
> devtools::check_rhub)
>
> When I submit to CRAN I have been notified that package 
> PHEindicatormethods_1.1.5.tar.gz does not pass the incoming checks 
> automatically, signposting failing pre-tests on Windows:
>
> * using R Under development (unstable) (2019-09-02 r77130)
>
> * using platform: x86_64-w64-mingw32 (64-bit)
>
> * using session charset: ISO8859-1
>
>
>
> This is the log file available for 7 days: 
> https://win-builder.r-project.org/incoming_pretest/PHEindicatormethods_1.1.5_20190905_224346/Windows/00check.log
>
> Below are two sections from the log that show the errors:
>
>
> > library('PHEindicatormethods')
>
> Error: package or namespace load failed for 'PHEindicatormethods' in 
> loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
>
>  there is no package called 'broom'
>
> Execution halted
>
> ** running examples for arch 'x64' ... ERROR
>
> Running examples in 'PHEindicatormethods-Ex.R' failed
>
> The error occurred in:
>
> R Under development (unstable) (2019-09-02 r77130) -- "Unsuffered 
> Consequences"
>
> Copyright (C) 2019 The R Foundation for Statistical Computing
>
> Platform: x86_64-w64-mingw32/x64 (64-bit)
>
>
> Error: processing vignette 'WorkedExamples_phe_sii.Rmd' failed with 
> diagnostics:
>
> package or namespace load failed for 'PHEindicatormethods' in 
> loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
>
>  there is no package called 'broom'
>
> --- failed re-building 'WorkedExamples_phe_sii.Rmd'
>
> SUMMARY: processing the following file failed:
>
>   'WorkedExamples_phe_sii.Rmd'
>
> Error: Vignette re-building failed.
>
> Execution halted
>
> I have checked the broom package and its upstream dependency on generics - I 
> notice the tidy() function was moved from broom to generics a while back but 
> this was before I submitted the current version (1.1.3) of my package to CRAN 
> so not sure this can be the problem, although one of my functions does 
> reference broom::tidy().  The evidence seems to point to changes in R-devel 
> causing something in my package to break but without being able to reproduce 
> the errors seen by CRAN I'm finding it difficult to pinpoint the problem.
>
> Thanks
> Georgie
>
>
> **
> The information contained in the EMail and any attachments is confidential 
> and intended solely and for the attention and use of the named addressee(s). 
> It may not be disclosed to any other person without the express authority of 
> Public Health England, or the intended recipient, or both. If you are not the 
> intended recipient, you must not disclose, copy, distribute or retain this 
> message or any part of it. This footnote also confirms that this EMail has 
> been swept for computer viruses by Symantec.Cloud, but please re-sweep any 
> attachments before opening or saving. http://www.gov.uk/PHE
> **
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] (Not) Reporting minimum R version in DESCRIPTION Depends Field

[Hadley Wickham]

On Fri, Jul 26, 2019 at 8:46 AM Ben Bolker  wrote:
>
>I'd add: as far as I know CRAN policy would only require you to
> report the minimum version if your package would fail on one of the
> older R versions that CRAN still tests (at present I think this goes
> back to 3.5.2).  For regular package developers (i.e.  without the
> resources of RStudio) it's a nuisance to install lots of old versions of
> R just to find out how far back your package actually works.

If you already use travis, this is pretty easy. All you need is something like:

matrix:
  include:
  - r: release
  - r: devel
  - r: oldrel
  - r: 3.4
  - r: 3.3
  - r: 3.2
  - r: 3.1

Obviously the challenge is making things work on older versions of R —
in our experience this is either really easy (i.e. you just
accidentally used a function that was added to R recently) or really
rather hard (your code on works in recent R because of bug that R core
fixed)

Hadley

> IMO it's a
> little bit obnoxious (albeit maybe unintentionally so) to prevent users
> who are stuck with earlier versions from using your package without a
> good reason.
>   (For this reason I try to save RData files that are included in my
> packages with version=2 so that users with R <3.5.0 aren't left out ...)
>
>   Unless you know that your package depends on features introduced in a
> particular version of R, I'd leave it out.  If you find out later from
> users that it breaks on earlier versions, and you can't find a way to
> enable its use on earlier versions, you can add the dependency in a
> later release.
>
>  Ben Bolker
>
> On 2019-07-26 10:20 a.m., Hadley Wickham wrote:
> > I no longer believe this to be good advice - I think you should only
> > declare a specific dependency if you want to strongly assert that your
> > package works with those versions. For example, all tidyverse versions
> > depend on R 3.2 and later, because we test on all those versions.
> >
> > Hadley
> >
> > On Friday, July 26, 2019, Jarrett Phillips 
> > wrote:
> >
> >> Hello,
> >>
> >> Numerous CRAN packages report minimum R versions within the Depends field
> >> of the DESCRIPTION file.
> >>
> >> Is this reporting always necessary?
> >>
> >> Hadley Wickham's book "R Packages" states:
> >>
> >> "You can also use Depends to require a specific version of R, e.g.
> >> Depends: R
> >> (>= 3.0.1) . As with packages, it’s a good idea to play it safe and require
> >> a version greater than or equal to the version you’re currently using.
> >> devtools::create()  will do this for you."
> >>
> >> devtools::check() doesn't warn about not specifying R version, so I am just
> >> curious.
> >>
> >>
> >> Thanks.
> >>
> >> Cheers,
> >>
> >> Jarrett
> >>
> >> [[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



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] (Not) Reporting minimum R version in DESCRIPTION Depends Field

[Hadley Wickham]

I no longer believe this to be good advice - I think you should only
declare a specific dependency if you want to strongly assert that your
package works with those versions. For example, all tidyverse versions
depend on R 3.2 and later, because we test on all those versions.

Hadley

On Friday, July 26, 2019, Jarrett Phillips 
wrote:

> Hello,
>
> Numerous CRAN packages report minimum R versions within the Depends field
> of the DESCRIPTION file.
>
> Is this reporting always necessary?
>
> Hadley Wickham's book "R Packages" states:
>
> "You can also use Depends to require a specific version of R, e.g.
> Depends: R
> (>= 3.0.1) . As with packages, it’s a good idea to play it safe and require
> a version greater than or equal to the version you’re currently using.
> devtools::create()  will do this for you."
>
> devtools::check() doesn't warn about not specifying R version, so I am just
> curious.
>
>
> Thanks.
>
> Cheers,
>
> Jarrett
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
http://hadley.nz

[[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] CRAN student assistants

[Hadley Wickham]

Hi all,

The thread seems to have drifted off topic. I really didn't want this
to devolve into a discussion about when cat() or message() is more
appropriate — I have complete faith in Jenny Bryan's ability to
understand technical tradeoffs and pick the most appropriate given the
constraints. I am most interested in understanding what level of
discretion CRAN's "Studentischer administrativer Mitarbeiter" have to
critique the implementation of R packages, particularly for packages
that do not yield R CMD check problems or otherwise violate CRAN
policies.

I mean no disrespect towards the CRAN maintainers (whose tireless
efforts are a crucial part of making R the success that it is), but I
don't think it's unreasonable to enquire as to who is involved in a
crucial piece of open source community infrastructure, and, if
students are involved, what their scope of work is and how they are
trained and supervised.

I do recognise that my question "Who are they?" may have been
perceived as overly intrusive. To clarify: I don't want to know names
or other personally identifying information, but I would like to know
in general terms how many there are, and what backgrounds they have.
Similarly, I don't want to know how much they are paid, just whether
or not they are volunteers or employees.

Hadley

On Tue, May 14, 2019 at 10:23 AM Hadley Wickham  wrote:
>
> Hi all,
>
> Several people on my team have received responses to their CRAN
> submissions from new members of the CRAN team who appear to be student
> assistants (judging from their job titles: "Studentischer
> administrativer Mitarbeiter"). From the outside, they appear to be
> exercising editorial control[^1] and conducting design reviews[^2].
>
> CRAN is a critical piece of R community infrastructure, and I am sure
> these students have been surrounded by the proper checks and balances,
> but it's not obvious what their role is from the outside. I'd really
> appreciate knowing a little more about them:
>
> * Who are they?
>
> * Are they paid employees or volunteers?
>
> * What is their scope of work?
>
> * How are they trained?
>
> * If we believe that they have made a mistake, how do we request
>   review from a senior CRAN member?
>
> * They appear to be able to apply additional discretionary criteria
>   that are not included in R CMD check or documented in the CRAN policies.
>   Is this true? If so, what is the scope of these additional checks?
>
> Hadley
>
> [^1]: The devoid package was rejected because the student assistant
> did not understand the purpose of the package.
>
> [^2]: The gargle package was rejected because the student assistant
> believed that the use of cat() was incorrect. It was not.
>
> --
> http://hadley.nz



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] CRAN student assistants

[Hadley Wickham]

Hi all,

Several people on my team have received responses to their CRAN
submissions from new members of the CRAN team who appear to be student
assistants (judging from their job titles: "Studentischer
administrativer Mitarbeiter"). From the outside, they appear to be
exercising editorial control[^1] and conducting design reviews[^2].

CRAN is a critical piece of R community infrastructure, and I am sure
these students have been surrounded by the proper checks and balances,
but it's not obvious what their role is from the outside. I'd really
appreciate knowing a little more about them:

* Who are they?

* Are they paid employees or volunteers?

* What is their scope of work?

* How are they trained?

* If we believe that they have made a mistake, how do we request
  review from a senior CRAN member?

* They appear to be able to apply additional discretionary criteria
  that are not included in R CMD check or documented in the CRAN policies.
  Is this true? If so, what is the scope of these additional checks?

Hadley

[^1]: The devoid package was rejected because the student assistant
did not understand the purpose of the package.

[^2]: The gargle package was rejected because the student assistant
believed that the use of cat() was incorrect. It was not.

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Hadley Wickham]

As of ~7 hours ago, the warning is suppressed:
https://github.com/wch/r-source/commit/31ee14c620eb1b939acd322f3b5617f998aab8e8

(But the service still doesn't work)

Hadley

On Thu, Mar 7, 2019 at 11:03 AM Hadley Wickham  wrote:
>
> It appears that the code was added by BDR on 2 Sep 2018:
> https://github.com/wch/r-source/commit/d839b1e04e173f90b51ad809ef0bdb18095abe6f
>
> I assume we are seeing failing R CMD check results because
> http://worldclockapi.com/api/json/utc/now has recently died.
>
> It would be appreciated if someone from R-core could look into this as
> it's currently causing all R-devel builds on travis to fail.
>
> Hadley
>
> On Thu, Mar 7, 2019 at 9:32 AM Bob Rudis  wrote:
> >
> > (a) that's gd news (#ty)
> > (b) genuine apologies for my confusion
> > (c) why was the introduction of reliance on a third-party site even under 
> > consideration?
> >
> > > On Mar 7, 2019, at 09:32, peter dalgaard  wrote:
> > >
> > > It's not "stealth fixed"! It was never there... (on the release branch)
> > >
> > > The timestamp checking code is still present in R-devel. I presume 
> > > something needs to be done about the breakage.
> > >
> > > - pd
> > >
> > >> On 7 Mar 2019, at 14:38 , Bob Rudis  wrote:
> > >>
> > >> It's fixed in the RC that's GA on the 11th.
> > >>
> > >> I think perhaps "stealth fixed" may be more appropro since it's not in 
> > >> SVN logs, Bugzilla nor noted prominently in any of the various NEWS* 
> > >> files.
> > >>
> > >> Then there's the "why was the core R installation using a third party, 
> > >> non-HTTPS site for this to begin with".
> > >>
> > >> And, in other news, there are tests in the R source that rely on a check 
> > >> of `foo.bar` for connectivity. `.bar` is a valid domain and `foo.bar` is 
> > >> registered. Thankfully there's no current IP address associated with it. 
> > >> Anything under `*.invalid` (https://en.wikipedia.org/wiki/.invalid) 
> > >> might be a better choice as well since that won't break the reason for 
> > >> the connectivity checks and won't arbitrarily send telemetry pings to 
> > >> third parties in the even anyone outside of R Core decides to run the 
> > >> tests (say, when patching something in R).
> > >>
> > >> -boB
> > >>
> > >>> On Mar 7, 2019, at 07:54, Rainer M Krug  wrote:
> > >>>
> > >>> I can confirm the same when checking on travis with r-devel.
> > >>>
> > >>> And thanks for the tip with
> > >>>
> > >>> env:
> > >>> - _R_CHECK_SYSTEM_CLOCK_=0
> > >>>
> > >>> In .travis.yml
> > >>>
> > >>> Seems to be working now
> > >>>
> > >>> Rainer
> > >>>
> > >>>
> > >>>
> > >>>> On 7 Mar 2019, at 12:48, Ralf Herold  wrote:
> > >>>>
> > >>>> Dear All,
> > >>>>
> > >>>> Checking a new package under development produces a warning in a local 
> > >>>> R-devel MS Windows environment (output below).
> > >>>>
> > >>>> Building it with R-devel on Travis fails (because warnings are changed 
> > >>>> to errors), but is successful when setting environment variable 
> > >>>> _R_CHECK_SYSTEM_CLOCK_ to zero.
> > >>>>
> > >>>> No issue occurs when checking and building with R-stable and R-oldrel 
> > >>>> on Travis, or with any R version on win-builder.r-project.org.
> > >>>>
> > >>>> The warning concerns using http://worldclockapi.com/, which however 
> > >>>> seems out of service ("The web app you have attempted to reach is 
> > >>>> currently stopped and does not accept any requests."). This is 
> > >>>> referenced in the main function for R CMD check 
> > >>>> (https://svn.r-project.org/R/trunk/src/library/tools/R/check.R) and 
> > >>>> may concern more R-devel than R-package-devel. I am posting here to 
> > >>>> check if the issue was noticed by other package developers and to 
> > >>>> check the impact.
> > >>>>
> > >>>> Thanks for any suggestions.
> > >>>> Best regards,
> > >>>> Ralf
>

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Hadley Wickham]

It appears that the code was added by BDR on 2 Sep 2018:
https://github.com/wch/r-source/commit/d839b1e04e173f90b51ad809ef0bdb18095abe6f

I assume we are seeing failing R CMD check results because
http://worldclockapi.com/api/json/utc/now has recently died.

It would be appreciated if someone from R-core could look into this as
it's currently causing all R-devel builds on travis to fail.

Hadley

On Thu, Mar 7, 2019 at 9:32 AM Bob Rudis  wrote:
>
> (a) that's gd news (#ty)
> (b) genuine apologies for my confusion
> (c) why was the introduction of reliance on a third-party site even under 
> consideration?
>
> > On Mar 7, 2019, at 09:32, peter dalgaard  wrote:
> >
> > It's not "stealth fixed"! It was never there... (on the release branch)
> >
> > The timestamp checking code is still present in R-devel. I presume 
> > something needs to be done about the breakage.
> >
> > - pd
> >
> >> On 7 Mar 2019, at 14:38 , Bob Rudis  wrote:
> >>
> >> It's fixed in the RC that's GA on the 11th.
> >>
> >> I think perhaps "stealth fixed" may be more appropro since it's not in SVN 
> >> logs, Bugzilla nor noted prominently in any of the various NEWS* files.
> >>
> >> Then there's the "why was the core R installation using a third party, 
> >> non-HTTPS site for this to begin with".
> >>
> >> And, in other news, there are tests in the R source that rely on a check 
> >> of `foo.bar` for connectivity. `.bar` is a valid domain and `foo.bar` is 
> >> registered. Thankfully there's no current IP address associated with it. 
> >> Anything under `*.invalid` (https://en.wikipedia.org/wiki/.invalid) might 
> >> be a better choice as well since that won't break the reason for the 
> >> connectivity checks and won't arbitrarily send telemetry pings to third 
> >> parties in the even anyone outside of R Core decides to run the tests 
> >> (say, when patching something in R).
> >>
> >> -boB
> >>
> >>> On Mar 7, 2019, at 07:54, Rainer M Krug  wrote:
> >>>
> >>> I can confirm the same when checking on travis with r-devel.
> >>>
> >>> And thanks for the tip with
> >>>
> >>> env:
> >>> - _R_CHECK_SYSTEM_CLOCK_=0
> >>>
> >>> In .travis.yml
> >>>
> >>> Seems to be working now
> >>>
> >>> Rainer
> >>>
> >>>
> >>>
>  On 7 Mar 2019, at 12:48, Ralf Herold  wrote:
> 
>  Dear All,
> 
>  Checking a new package under development produces a warning in a local 
>  R-devel MS Windows environment (output below).
> 
>  Building it with R-devel on Travis fails (because warnings are changed 
>  to errors), but is successful when setting environment variable 
>  _R_CHECK_SYSTEM_CLOCK_ to zero.
> 
>  No issue occurs when checking and building with R-stable and R-oldrel on 
>  Travis, or with any R version on win-builder.r-project.org.
> 
>  The warning concerns using http://worldclockapi.com/, which however 
>  seems out of service ("The web app you have attempted to reach is 
>  currently stopped and does not accept any requests."). This is 
>  referenced in the main function for R CMD check 
>  (https://svn.r-project.org/R/trunk/src/library/tools/R/check.R) and may 
>  concern more R-devel than R-package-devel. I am posting here to check if 
>  the issue was noticed by other package developers and to check the 
>  impact.
> 
>  Thanks for any suggestions.
>  Best regards,
>  Ralf
> 
> 
>  PS C:\Users\username> & 'C:\Program Files\R\R-devel\bin\R.exe' CMD check 
>  E:\mypackage_0.1.2.3.tar.gz --as-cran
>  * using log directory 'C:/Users/username/ctrdata.Rcheck'
>  * using R Under development (unstable) (2019-03-05 r76200)
>  * using platform: x86_64-w64-mingw32 (64-bit)
>  * using session charset: ISO8859-1
>  * using option '--as-cran'
>  [...]
>  * checking package directory ... OK
>  * checking for future file timestamps ...Warning in file(con, "r") :
>  cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP status 
>  was '403 Site Disabled'
>  WARNING
>  unable to verify current time
>  * checking 'build' directory … OK
>  [...]
> 
> 
> 
>  ## Ralf Herold
>  ## mailto: ralf.her...@mailbox.org [S/MIME]
>  ## https://paediatricdata.eu/
> 
>  __
>  R-package-devel@r-project.org mailing list
>  https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Rainer M. Krug
> >>> email: Rainerkrugsde
> >>> PGP: 0x0F52F982
> >>>
> >>>
> >>> [[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
> >
> > --
> > Peter Dalgaard, Professor,
> > Center for 

Re: [R-pkg-devel] submitting to github

[Hadley Wickham]

No one else has mentioned it on the thread, so I'd highly recommend
https://happygitwithr.com — it's a guide to git + github specifically
written for R users, and covers many of the common problems people
have when getting set up.

Hadley

On Fri, Jan 25, 2019 at 2:51 AM Troels Ring  wrote:
>
> Dear friends - I'm sorry to bother but seem to be unable to interact
> constructively with github.
>
>
>
> I try to follow the instructions from Hadley (thanks) - i.e. I have a
> small trial-project which functions well. Since I have tried many times I
> start from shell with
>
> rm -rf .git
>
> and then select version control using git (tools, project options,git/svn) -
> and origin is still marked as "none" after restarting RStudio.
>
> Then from shell again: git init
>
> Yielding
>
> Initialized empty Git repository in
> C:/Users/Troels/Dropbox/Rown/ABCharge/.git/
>
> Rstudio restarted, package reopened: origin still "none"
>
> Git panel appears OK.
>
>
>
> Now from github: add new repository (non present after prior deletions!)
>
> Named as package name - repeated in description - repository created
>
>
>
> Shell opened from RStudio
>
> git remote add origin https://github.com/troelsring/ABCharge.git  - works
> without problems - an origin seems correctly accepted in RStudio - but then:
>
> git push -u origin master  - results in:
>
>
>
> error: src refspec master does not match any.
>
> error: failed to push some refs to
> 'https://github.com/troelsring/ABCharge.git' below in red
>
>
>
> I seem (also!) to have problems with the SSH keys - Rstudio marks that I
> have a key in c:/Users/Troels/.ssh/id_rsa -
>
> but when I run file.exists("~/.ssh/id_rsa.pub")
> [1] FALSE -  Is returned - but that is not the issue I guess? I have anyway
> made a public key as suggested.
>
> I have spent hours seeking on the many pages for explanation for this
> probably simple problem.
> All best
> Troels
>
>
>
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] New CRAN internet policy

[Hadley Wickham]

On Fri, Dec 7, 2018 at 2:48 AM Martin Maechler
 wrote:
>
> >>>>> Hadley Wickham
> >>>>> on Thu, 6 Dec 2018 10:22:47 -0600 writes:
>
> > Hi all,
> > I'd love to get some clarification on what the new internet policy
> > means for packages like httr:
>
> >> Packages which use Internet resources should fail gracefully with an 
> informative
> >> message if the resource is not available (and not give a check warning 
> nor error).
>
> > It's not clear what "internet resource" means here? If it means
> > dataset, then I think the httr tests and examples are ok. If it means
> > any use of the internet, I'm not sure what do - httr critically
> > depends on internet access, so I can't see any way to make it fail
> > gracefully.
>
> > Hadley
>
> I cannot answer your question, notably as I'm not part of the CRAN
> team, but as R Core developer, I've encountered the problem
> many times which this policy tries to mitigate
> (but I also think we should consider to go further than the
>  above "policy") :
>
> As R developer, I'd like to see the effect of a change to the
> sources of base R, and so eventually, I may want to run the
> equivalent of 'R CMD check' on all existing CRAN and
> Bioconductor packages. If I have access to a server with many
> cores and very fast hard disks, I can hope to finish running the
> tests with 1--2 days.
> But then I have to deal with the result.  The few times I've
> done this, the result has been "a mess" because many many
> packages  nowadays assume in their examples and their regression/unit
> tests that internet access to some resources works, ... which it
> "often" does not, and so  download.file(),
> read.table("http://.;) etc result in errors sooner or later.
>
> Because of that some packages fail their checks "randomly" (in
> the sense that internet resources are not available "randomly").
> Ideally we'd find a very good way that these failures are
> communicated back to the person / process running (a version of)
> 'R CMD check', because in the above scenario, I'd like to weed
> out the 300 packages that just failed because of internet
> resource access failures,  and only look at the other packages
> that got a change in their 'R CMD check' results.

We have now decent tooling for this in revdepcheck
(https://www.github.com/r-lib/revdepcheck, planning for CRAN
submission next year). After performing all the revdepchecks, you can
run revdep_add_broken() to recheck packages that failed in the
previous round - in my experience testing httr (whose revdeps
obviously use the internet a lot) this resolves most of the randomness
(since it's fairly unlikely to get two random failures in a row).

My main concern about making the checking in examples and tests
stricter is that I think the primary result is that people will simply
do less testing and write fewer realistic examples, which is a net
negative for the community. When you want people to do the right
thing, I think you have to provide a carrot along with the stick.

> The recent introduction in R-devel of classed error conditions
> (in some cases), e.g., 
> https://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2018/10/04#n2018-10-04,
>   and the similar and somewhat earlier
> effort of Lionel Henry to use classed error conditions (in
> rlang only, unfortunately, rather than as a patch proposal to R ..)
> maybe one step towards a nice solution here.

We'd be happy to propose a patch to base R, but it's not yet clear to
us exactly how things should work so I think it makes the most sense
to first prototype in a package.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Package update submission to CRAN fails on pretest

[Hadley Wickham]

You might try reinstalling devtools and dependencies - there was
unfortunately a brief combination of versions that lead to build()
failing to overwrite existing files.

Hadley
On Fri, Dec 7, 2018 at 10:46 AM Wolfgang Lenhard
 wrote:
>
> Many thanks for the remark. It seems, it has something to do with
> submitting via the devtools (maybe I did something wrong with tagging
> the prior release). Submitting it manually at least does not result in
> pretest rejection. I guess there is something out of sync which resulted
> in rechecking and old version.
>
> Am 07.12.2018 um 13:46 schrieb Georgi Boshnakov:
> > The link you gave, 
> > https://cran.r-project.org/web/checks/check_results_cNORM.html,
> > is to the check results for the package currently on CRAN and it is indeed 
> > v. 1.0.1
> > (it is linked from https://CRAN.R-project.org/package=cNORM).
> >
> > Was this really the link you got from CRAN's pretest? Sometimes they ask if 
> > care has been taken about NOTEs/WARNINGs for the current CRAN version, 
> > since some tests are not done during submission, but this doesn't seem the 
> > case here.
> >
> > Georgi Boshnakov
> >
> >
> > -Original Message-
> > From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On 
> > Behalf Of Wolfgang Lenhard
> > Sent: 07 December 2018 07:55
> > To: r-package-devel@r-project.org
> > Subject: [R-pkg-devel] Package update submission to CRAN fails on pretest
> >
> > Dear list,
> > I am getting problems when trying to submit an update of the package
> > cNORM to CRAN. I am developing the package with RStudio and devtools and
> > I am using Travis for automatic testing. The package is tested locally
> > on Win10 and Mac OS X and on Travis with Ubuntu and Mac both for
> > development and release versions of R. All local tests and tests on
> > Travis work flawlessly - no errors, warning or notes. When submitting to
> > CRAN, a note and an error show up on some of the Linux OS (Fedora &
> > Solaris) and Mac OS X, while others display an 'OK' (Win, Debian). The
> > results: https://cran.r-project.org/web/checks/check_results_cNORM.html
> >
> > - error: This seems to be related to the vignette with the following
> > message:
> >> * checking examples ... ERROR
> >> Running examples in ‘cNORM-Ex.R’ failed
> > I can however not identify the location of the error
> >
> > - Note: Check: data for non-ASCII characters
> >
> > The strange thing is: I checked all data files multiple times. They
> > mainly consist of data.frames with numerics and all colnames  are ASCII.
> > I am not able to replicate the issue. The same is true for the error,
> > which does not show up on Travis and as well locally. And finally, the
> > results state, that the version of the package is 1.0.1, which had been
> > the first submission to CRAN a month ago. The current version of the
> > package is 1.1.1. Could this be the reason for the problem?
> >
> > Do you have an idea how to progress with the testing or how to locate
> > the errors? Any help is welcome.
> >
> > Best regards,
> >   Wolfgang Lenhard
> >
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Prof. Dr. Wolfgang Lenhard
> Lehrstuhl Psychologie IV
> Raum 02.130
> Wittelsbacherplatz 1
> D-97070 Würzburg
>
> Tel.: 0931 3189791
> FAX:  0931 3184891
> URL:  https://go.uniwue.de/lenhard
> Map:  https://go.uni-wuerzburg.de/3b
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Suggested package relies on recent R

[Hadley Wickham]

Can you just set _R_CHECK_FORCE_SUGGESTS_=false?

env:
  global:
  # don't treat missing suggested packages as error
  - _R_CHECK_FORCE_SUGGESTS_=false

I am reasonably certain that is what CRAN uses.

Hadley

On Fri, Dec 7, 2018 at 9:11 AM David Hugh-Jones
 wrote:
>
> Hi,
>
> My package Suggests a package that relies on R >= 3.5.0. My package works
> fine with earlier R, though. When travis runs R CMD check on R-oldrel,
> therefore, it fails because it can't install the suggested package.
>
> Is this going to stop me submitting to CRAN? I don't really want to require
> R 3.5.0 just to satisfy an optional dependency.
>
> Cheers,
> David
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] New CRAN internet policy

[Hadley Wickham]

Policies at https://cran.r-project.org/web/packages/policies.html

Dirk Eddelbuettel has a CRAN policy watch where you can see the
changes: https://github.com/eddelbuettel/crp

Hadley

On Thu, Dec 6, 2018 at 10:42 AM Roy Mendelssohn - NOAA Federal
 wrote:
>
> Hi All:
>
> Can someone point me to where all the policies such as this one are posted.  
> This may affect a package I have,  and one problem I have is different people 
> have differing ideas of what defines a "graceful" exit.
>
> Thanks,
>
> Roy
>
>
> > On Dec 6, 2018, at 8:22 AM, Hadley Wickham  wrote:
> >
> > Hi all,
> >
> > I'd love to get some clarification on what the new internet policy
> > means for packages like httr:
> >
> >> Packages which use Internet resources should fail gracefully with an 
> >> informative
> >> message if the resource is not available (and not give a check warning nor 
> >> error).
> >
> > It's not clear what "internet resource" means here? If it means
> > dataset, then I think the httr tests and examples are ok. If it means
> > any use of the internet, I'm not sure what do - httr critically
> > depends on internet access, so I can't see any way to make it fail
> > gracefully.
> >
> > Hadley
> >
> > --
> > http://hadley.nz
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> **
> "The contents of this message do not reflect any position of the U.S. 
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov www: http://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
>


-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] creating a link to a vignette in a .Rd file

[Hadley Wickham]

> None of these solutions seem perfect to me. I think that my suggestion is the 
> most natural, but as you point out it won’t work in all contexts. Perhaps the 
> safest approach is to give the vignette() command in the text of the help 
> file, one of your suggestions.

If you do that, and you use pkgdown (https://pkgdown.r-lib.org), that
code chunk will automatically be linked to the vignette when you build
the website.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] creating a link to a vignette in a .Rd file

[Hadley Wickham]

On Mon, Nov 19, 2018 at 4:49 PM Fox, John  wrote:
>
> Dear r-package-devel list members,
>
> I'd like to create a link to a package vignette from a help file in the same 
> package, for example to the "partial-residuals" vignette in the effects 
> package from effect.Rd. I'm able to generate a URL for the vignette as 
> follows:
>
> \Sexpr[results=text]{paste0("file://", system.file("doc", 
> "partial-residuals.pdf", package="effects"))}
>
> but I'm unable to link to the resulting text string using href{}{} or url{} 
> because \Sexpr[etc]{etc.} is treated as verbatim text rather than evaluated.
>
> Is there a way around this problem or another approach that works?

Have you confirmed that a raw file:// url works?  I would be mildly
surprised if it did, given my understanding of how web browser
security works (which is patchy, but you should still check before
going too far down this path).

Don't you just need `results=rd` ?

\Sexpr[results=rd]{paste0("\\url{file://", system.file("doc",
"partial-residuals.pdf", package="effects"), "}")}

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Extending/adding to an R6 class from another package: qns

[Hadley Wickham]

> AzureRMR: the "base" package, provides a number of R6 classes
> AzureVM: a "child" package that extends classes from AzureRMR with extra 
> functionality related to virtual machines
> AzureStor: another child package that extends classes from AzureRMR, this 
> time for storage accounts
> Etc.
>
> For example, AzureRMR defines a class called "az_resource_group" that 
> represents an Azure resource group. Within this class, I have convenience 
> functions to manage individual Azure resources: 
> az_resource_group$get_resource(), az_resource_group$create_resource(), etc. 
> One benefit of this approach is that method chaining works: I can do 
> something like
>
>az_subscription("xxx")$get_resource_group("yyy")$get_resource("zzz").
>
> In my child packages, I then define further classes and methods for dealing 
> with specific services. For consistency, I also add convenience functions to 
> the base AzureRMR::az_resource_group class to work with these new classes. 
> For example, AzureVM defines a new class az_vm_template, and also adds a 
> $get_vm() method to AzureRMR::az_resource_group.
>
> Running devtools::check() however brings up a note and warning for the child 
> packages. For example, with AzureVM:
>
> * checking R code for possible problems ... NOTE
> File 'AzureVM/R/add_methods.R':
>   .onLoad calls:
> message("Creating resource group '", resource_group, "'")
>
> Package startup functions should use 'packageStartupMessage' to  generate 
> messages.
> See section 'Good practice' in '?.onAttach'.
>
> . . .
>
> * checking for code/documentation mismatches ... WARNING
> Functions or methods with usage in documentation object 'get_vm' but not in 
> code:
>   get_vm get_vm_cluster list_vms
>
>
> The reason for the note is because modifying R6 classes from another package 
> has to be done at runtime, ie, in the .onLoad function. The message() call 
> referred to is inside one of the new methods that I define for an AzureRMR 
> class, hence it never actually appears at package startup. I assume it's okay 
> to ignore this note?

I think monkey-patching classes on load is an extremely bad idea. You
would be better off subclassing, or if the classes are so closely
inter-related, you should put them in a single package. Or re-design
your interface to use the pipe instead of method chaining so this
isn't a problem (brief discussion at
https://adv-r.hadley.nz/oo-tradeoffs.html#tradeoffs-pipe)

> The reason for the warning is because writing documentation for R6 methods is 
> rather awkward, even/especially with Roxygen. This goes doubly so when the 
> method in question is for a class from a different package. What I've done is 
> to write a Roxygen block for the method as if it was a standalone function; 
> for example, the documentation for az_resource_group$get_vm() is like this:
>
> #' Get existing virtual machine(s)
> #'
> #' Method for the [AzureRMR::az_subscription] and 
> [AzureRMR::az_resource_group] classes.
> #'
> #' @rdname get_vm
> #' @name get_vm
> #' @usage
> #' get_vm(name)
> #' get_vm(name, resource_group = name)
> #'
> #' @param name The name of the VM or cluster.
> #' @param resource_group For the `az_subscription` method, the resource group 
> in which `get_vm()` will look for the VM. Defaults to the VM name.
> #'
> #' @details
> #' ...
> NULL
>
> This way, typing ?get_vm will bring up the relevant page, which seems to me 
> to be the best compromise in terms of the end-user experience. Is this an 
> acceptable way of doing the documentation for CRAN?

I think the usage should be consistent with how people actually call
the function, i.e. x$get_vm(name). I'm not sure if R CMD check will
like this, but I suspect it will silence the warning.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] stringi update

[Hadley Wickham]

Looking at the primary CRAN site:
https://cran.r-project.org/web/packages/stringi/index.html, you can
see that the windows binary is still at 1.1.7, suggesting that there's
some build failure. You can see exactly what that is on the CRAN check
page: https://cran.r-project.org/web/checks/check_results_stringi.html

Hadley
On Sat, Sep 15, 2018 at 1:24 AM Patrick Giraudoux
 wrote:
>
> Thnaks for the hint, but I have tried several  mirrors and still get the
> same trouble:
>
>  > update.packages(ask='graphics',checkBuilt=TRUE)
>
>There are binary versions available but the source versions are later:
>  binary source needs_compilation
> stringi  1.1.7  1.2.4  TRUE
>
> Do you want to install from sources the packages which need compilation?
> y/n:
>
> Which re-install the same version at each update...
>
>
>
>
> Le 10/09/2018 à 17:17, R. Mark Sharp a écrit :
> > Patrick,
> >
> > It looks like the CRAN mirror that you are using has not been updated with 
> > the binary versions, which are readily available on other mirrors (e.g., 
> > https://cran.revolutionanalytics.com).
> >
> > Mark
> > R. Mark Sharp, Ph.D.
> > Data Scientist and Biomedical Statistical Consultant
> > 7526 Meadow Green St.
> > San Antonio, TX 78251
> > mobile: 210-218-2868
> > rmsh...@me.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >> On Sep 10, 2018, at 12:23 AM, Patrick Giraudoux 
> >>  wrote:
> >>
> >> Since weeks the package stringi stays on the following versions:
> >>
> >>> update.packages(ask='graphics',checkBuilt=TRUE)
> >>There is a binary version available but the source version is later:
> >>  binary source needs_compilation
> >> stringi  1.1.7  1.2.4  TRUE
> >>
> >> Do you want to install from sources the package which needs compilation?
> >> y/n: n
> >>
> >> However updated,  I am asked to update it again with the same version at 
> >> any next update of R.
> >>
> >> Has somebody an idea about what is happening?
> >>
> >> Patrick
> >>
> >> __
> >> 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



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Submission to CRAN when package needs personal data (API key)

[Hadley Wickham]

On Fri, Sep 7, 2018 at 9:13 AM Iñaki Ucar  wrote:
>
> El vie., 7 sept. 2018 a las 16:03, Ralf Stubner
> () escribió:
> >
> > On 07.09.2018 15:52, Iñaki Ucar wrote:
> > > For the record, this is what the testthat paper in the R Journal says:
> > >
> > > "[...] I recommend storing your tests in inst/tests/ (so users also
> > > have access to them), then including one file in tests/ that runs all
> > > of the package tests. The test_package(package_name) function makes
> > > this easy. [...] This setup has the additional advantage that users
> > > can make sure your package works correctly in their run-time
> > > environment."
> >
> > Tests in 'inst/test' got deprecated later on:
> >
> > https://github.com/r-lib/testthat/commit/0a7d27bb9ea545be7da1a10e511962928d888302
>
> Yeap, and I was pointing out the *old* (2011) practice and
> recommendation. The reason why this evolved and changed, that I don't
> know.

Because CRAN specifically asked me to put testthat tests in tests/
(R's standard testing directory), rather that somewhere non-standard.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Submission to CRAN when package needs personal data (API key)

[Hadley Wickham]

On Wed, Sep 5, 2018 at 3:03 PM Duncan Murdoch  wrote:
>
> On 05/09/2018 2:20 PM, Henrik Bengtsson wrote:
> > I take a complementary approach; I condition on, my home-made,
> > R_TEST_ALL variable.  Effectively, I do:
> >
> > if (as.logical(Sys.getenv("R_TEST_ALL", "FALSE"))) {
> > ...
> > }
> >
> > and set R_TEST_ALL=TRUE when I want to run that part of the test.  You
> > can also imagine refined versions of this, e.g. R_TEST_SETS=foo,bar
> > and test scripts with:
> >
> > if ("foo" %in% strsplit(Sys.getenv("R_TEST_SETS"), split="[, ]+")[[1]]) {
> > ...makes no assumption
> > }
> >
> > That avoids making assumptions on where the tests are submitted/run,
> > may it be CRAN, Bioconductor, Travis CI, ...
>
> This is the right way to do it.

I would like to gently push back on this assertion: if CRAN set an
environment variable we would have one single convention that all
packages could rely on. The current system relies on each package
author evolving their own solution. This makes life difficult when you
are running local reverse dependency checks: there is no way to
systematically assert that you want to run tests in a way as similar
as possible to CRAN.

I know that the CRAN maintainers already have a very large workload,
and I hate to add to it, but setting CRAN=1 in a few profile files
doesn't seem excessively burdensome.

> This discussion has come up before.  If you want to submit to CRAN, you
> should include tests that satisfy their requests.  If you want even more
> tests, there are several ways to add them in addition to the CRAN tests.
>   Henrik's is one, "R CMD check --test-dir=myCustomTests" is another.
>
> Rainer's package is unusual, in that from his description it can't
> really work unless the user obtains an API key.  There are other
> packages like that, and those cases need manual handling by CRAN:  they
> don't really run full tests by default.  But the vast majority of
> packages should be able to live within the CRAN guidelines.

10 years ago, I would have definitely supported this statement. But I
am not sure it is still correct today, as there are now many packages
that require a connection to web API to work (or depend on a package
that uses an API). Additionally, CRAN only allows a limited amount of
compute time for each check, so there are often longer tests that you
want to run locally but not on CRAN. CRAN is a specialised testing
service and it does have different constraints to your local machine,
travis, and bioconductor.

A quick search of the CRAN mirror on github
(https://github.com/search?q=org%3Acran+skip_on_cran=Code)
reveals that there are ~2700 tests that use testthat::skip_on_cran().
This is obviously an underestimate of the total number of tests
skipped on CRAN, as many packages don't use testthat, or use an
alternative technique to avoid running code on CRAN.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN incoming queue closed from Sep 1 to Sep 9

[Hadley Wickham]

Does this include automatically (bot) accepted submissions?
Hadley
On Tue, Aug 14, 2018 at 8:07 AM Uwe Ligges
 wrote:
>
> Dear package developers,
>
> the CRAN incoming queue will be closed from Sep 1 to Sep 9. Hence
> package submissions are only possible before and after that period.
>
> Best,
> Uwe Ligges
> (for the CRAN team)
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Weird error on CRAN linux check

[Hadley Wickham]

I don't think it's related to the error, but you shouldn't be exporting this:

export("align<-.huxtable")

You should generally only export the method.

Hadley

On Wed, Jul 4, 2018 at 9:00 AM, David Hugh-Jones
 wrote:
> Hi all,
>
> The following shows an error for my package:
> https://www.r-project.org/nosvn/R.check/r-release-linux-x86_64/huxtable-00check.html
>
> Here's an excerpt:
>
>> ### ** Examples
>>
>>
>> ht <- huxtable(a = 1:3, b = 1:3)
>> align(ht) <- 'right'
> Error in UseMethod("align<-") :
>   no applicable method for 'align<-' applied to an object of class
> "c('huxtable', 'data.frame')"
> Calls: align<-
>
>
> The error didn't show up on win-builder, travis, appveyor or my own
> computer (a mac). The package defines an `align<-.huxtable` method which is
> correctly loaded on my computer, and the NAMESPACE file contains these
> lines:
>
> S3method("align<-",huxtable)
> export("align<-")
> export("align<-.huxtable")
>
> Has anyone got any ideas?
>
> David
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Errors from Suggests or Enhances not in mainstream repositories

[Hadley Wickham]

On Tue, Jul 3, 2018 at 5:57 AM, Duncan Murdoch  wrote:
> On 02/07/2018 6:13 PM, Ben Bolker wrote:
>>
>> I got something similar.  I have a few thoughts:
>>
>> (1) you should use  "if (require(citrus)) { ... }" in your examples;
>> "Suggests" and "Enhances" packages are supposed to be *optional*, i.e.
>> examples and tests should be able to run even if they're not installed
>
>
> Nowadays 'if (requireNamespace("citrus")) { ... }' would be preferred in
> tests and examples, along with a 'citrus::' prefix on the objects from that
> package that are needed.  This has milder side effects than `require()`.

And requireNamespace("citrus", quietly = TRUE) is even slightly better
since it avoids one more side-effect ;)

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN pretest archived because of 2 NOTEs

[Hadley Wickham]

For the purposes of CRAN submission, you should basically treat every
NOTE as an ERROR.

Hadley

On Wed, Apr 18, 2018 at 3:36 AM, Gertjan van den Burg
 wrote:
> While waiting to get this message posted to the list, I've solved the
> problem by copying the stdlib rand() and srand() functions into my package
> under a different name. This makes the check pass and ensures my RNG does
> not interfere with R's RNG.
>
> I do think that if this NOTE causes immediate dismissal of a package, it
> shouldn't be a NOTE but an ERROR. Otherwise it just leads to a lot of wasted
> time waiting for a reply from the maintainers to respond to the note.
>
>> Dear all,
>>
>> My CRAN submission doesn't pass the pre-tests and gets archived. I've
>> emailed cran-submissi...@r-project.org explaining that these are false
>> positives, but since I haven't heard back in 10 days I don't think anyone
>> read that. Same thing for the submission comments (which also explained
>> it).
>>
>> The first note is:
>>
>> * checking CRAN incoming feasibility ... NOTE
>> Maintainer: ‘Gertjan van den Burg ’
>>
>> New submission
>>
>> Possibly mis-spelled words in DESCRIPTION:
>>GenSVM (8:18, 10:61, 15:2, 16:26, 19:11)
>>Multiclass (4:22)
>>SVMs (14:25, 15:42)
>>misclassifications (11:49)
>>multiclass (8:53, 14:14, 15:31)
>>
>>
>> These words are not mis-spelled, so this is a false positive.
>>
>> The second note is:
>>
>> * checking compiled code ... NOTE
>> File ‘gensvm/libs/gensvm_wrapper.so’:
>>Found ‘rand’, possibly from ‘rand’ (C)
>>  Objects: ‘gensvm/src/gensvm_cv_util.o’, ‘gensvm/src/gensvm_init.o’,
>>‘gensvm/lib/libgensvm.a’
>>Found ‘srand’, possibly from ‘srand’ (C)
>>  Objects: ‘gensvm/src/gensvm_train.o’, ‘gensvm/lib/libgensvm.a’
>>
>> Compiled code should not call entry points which might terminate R nor
>> write to stdout/stderr instead of to the console, nor use Fortran I/O
>> nor system RNGs.
>>
>> See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual.
>>
>>
>> This is probably why the package is rejected. I have a valid use case for
>> using rand() and srand(): I'm trying to maintain compatibility of this
>> package with the corresponding Python package. By using rand en srand
>> users
>> can reproduce models in both languages.
>>
>> Does anyone have any ideas on how I can get the package excepted to CRAN?
>>
>> Thanks,
>>
>> Gertjan van den Burg
>>
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] GPL + other licence

[Hadley Wickham]

On Tue, Apr 10, 2018 at 2:45 AM, Kasper Daniel Hansen
 wrote:
> There are 3 solutions.  (1) You (get permission) to change the library to
> GPL.  (2) You get permission to change the license of the R code to
> whatever license the library is released under.  (3) you split the package.

For completeness: (4) you find a license that is compatible with both
the license of QHull and the license of the existing R package.

> You have investigated (1) and it does not work.  I would suggest thinking
> about (2) provided the license of the library is decent.  This is what we
> did with Rgraphviz some years ago; Graphviz itself is licensed under the
> Eclipse public license and there was no way I could get a company to change
> the license of that code.
>
> I would do whatever I can to avoid splitting the package.
>
> Best,
> Kasper
>
> On Fri, Apr 6, 2018 at 8:44 PM, David C Sterratt 
> wrote:
>
>> Dear all,
>>
>> I'd appreciate help with a licence conundrum I have with the geometry
>> package (https://davidcsterratt.github.io/geometry/) that I maintain.
>>
>> The geometry package contains some functions (e.g. convhulln(),
>> delaunayn()) that wrap the Qhull library (http://www.qhull.org), which
>> has its own, non-GPL, licence. The geometry package includes this source
>> code, and wraps it in C files that have GPL licence headers.
>>
>> The geometry package also has functions that are not derived from Qhull
>> code and which are licensed under GPL, including a number of functions
>> that are ports of the Matlab distmesh package, and some other useful
>> functions to do with triangulation and coordinate systems (e.g.
>> tsearch() and cart2bary()).
>>
>> I inherited this situation when I took over maintaining the package 8
>> years ago, though I have added functions to both Qhull-derived and GPL
>> categories.
>>
>> In October last year I submitted the latest version of the geometry
>> package, which adds quite a bit of useful functionality:
>> https://github.com/davidcsterratt/geometry/blob/master/pkg/NEWS
>>
>> I received the following response from the CRAN maintainers:
>>
>>   For the license. It is CRAN policy that a package has to have a single
>>   license. Can you manage to convince all copyright hoders (e.g. of
>>   Qhull) to relicense under GPL?
>>
>> I tried persuading the author of Qhull. He replied:
>>
>>   There's only one license and that's the one included with the code
>>   (COPYING.txt). Several years ago, I tried to clarify the license with
>>   the Univ. of Minn. but had no success. So I think the best approach is
>>   to keep the original license as is. It has not been an issue so far.
>>
>> At the same time as I wrote to the Qhull maintainer, I wrote to the CRAN
>> maintainers:
>>
>>   I have written to the Qhull maintainer, but I doubt he will want to
>>   change the license, since Qhull is used in proprietary software such
>>   as MATLAB. Assuming this is the case, we'll have to create a new
>>   package - I would need help with managing the change for dependent
>>   packages.
>>
>> The CRAN maintainers replied:
>>
>>   Please try to find out how this can work.
>>
>> In principle I could create a package containing only the functions
>> derived from Qhull (but still with GPL headers in the wrapper C files,
>> see e.g.,
>> https://github.com/davidcsterratt/geometry/blob/
>> master/pkg/src/Rconvhulln.c
>> But wouldn't this package still have to have two licenses, due to the
>> GPL headers?
>>
>> I don't want to start on any package splitting without having a plan
>> agreed that I know will be OK for CRAN. It would be quite a bit of work,
>> as there are a number of packages that depend on geometry, so I would
>> have to check all the revdeps for functions that they call in the
>> geometry package. I would have to then perhaps write wrapper functions
>> in the geometry package to make sure any functions moved to a new
>> package still worked when called from revdeps.
>>
>> I know the CRAN maintainers are busy, so any help from the list would be
>> much appreciated.
>>
>> Best wishes,
>>
>> David.
>>
>> --
>> David C Sterratt, Senior Research Associate
>> Institute for Adaptive and Neural Computation, School of Informatics
>> University of Edinburgh, 10 Crichton Street, Edinburgh EH8 9AB, Scotland,
>> UK
>> http://homepages.inf.ed.ac.uk/sterratt - tel: +44 131 651 1739
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>> __
>> 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



-- 
http://hadley.nz

__

Re: [R-pkg-devel] R package CRAN check error

[Hadley Wickham]

Or even better, devtools::release(): it walks you through a checklist
of activities designed to make your submission as successful as
possible.

Hadley

On Fri, Feb 16, 2018 at 2:46 PM, Georgi Boshnakov
 wrote:
> You get a source package suitable for submission by running `R CMD check 
> namepackage'  or the equivalent devtools::build()
>
> Georgi
>
> -Original Message-
> From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On 
> Behalf Of Ilaria Amerise
> Sent: 16 February 2018 11:35
> To: r-package-devel
> Subject: [R-pkg-devel] R package CRAN check error
>
> Hi everybody,
>
> on submitting a new version of a package I got a rejection because of the 
> following Error in the CRAN-check.
>
> Any help would be highly appreciated.
>
> * using R version 3.4.3 (2017-11-30)
> * using platform: x86_64-apple-darwin15.6.0 (64-bit)
> * using session charset: UTF-8
> * using option ‘--as-cran’
> * checking for file ‘namepackage/DESCRIPTION’ ... OK
> * checking extension type ... Package
> * this is package ‘namepackage’ version ‘1.1.2’
> * checking CRAN incoming feasibility ... Note_to_CRAN_maintainers
> * checking package namespace information ... OK
> * checking package dependencies ... OK
> * checking if this is a source package ... ERROR Only *source* packages can 
> be checked.
> * DONE
> Status: 1 ERROR
>
> Best regards,
> Ilaria
>
> __
> 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



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Windows binaries

[Hadley Wickham]

devtools::build_win() has an unfortunate name - it's actually more
about checking your package on windows than building a package (and in
the development version we've renamed to check_win()). However,
fortunately, once your package has been accepted on CRAN, you don't
need to worry about building windows binaries - CRAN will take care of
that for you.

Hadley

On Wed, Feb 14, 2018 at 3:14 PM, Kapur, Kush
 wrote:
> Dear R development team,
>
>
> I have also submitted the Windows binaries for the ssrm.logmer package using 
> build_win function in devtools.
>
> Is there anything else I need to take care of to make sure this package can 
> be installed on windows system?
>
>
>
> Best,
>
> Kush
>
>
> Kush Kapur, PhD
> Assistant Professor of Neurology
> Department of Neurology | Boston Children's Hospital
> Senior Statistician
> Biostatistics and Research Design Core | Clinical and Translational Research
> Associate Director of Biostatistics
> Harvard Catalyst | The Harvard Clinical and Translational Science Center
> Harvard Medical School | Ph: 857-218-4955
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Fwd: R CMD check and strange ## Not run strings

[Hadley Wickham]

> This actually is not about Rd format. Indeed, you are using   'roxygen' 
> syntax.

This is unrelated to roxygen. \dontrun{} is Rd formatting.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Conditionally register method with generic in other package

[Hadley Wickham]

We use this technique in a couple of places:
https://github.com/tidyverse/dbplyr/blob/6be777d8b23d588f19c98de52f4e58f16c2ef67e/R/zzz.R

Basic idea is to call registerS3method() manually, when needed - it's
just a little tricky because the suggested package may be loaded
either before or after your package.

Hadley

On Thu, Dec 7, 2017 at 1:45 AM, Joshua Ulrich  wrote:
> I have a feeling I know the answer to this question, but I'm asking
> with the hope that I learn something new.
>
> Package A defines a S3 generic function, "foo()".  Package B defines a
> S3 class "bar", and a foo.bar() method.  This method is not strictly
> necessary for the package to function, and package A has many
> dependencies.
>
> To avoid excessive dependencies, I would like to only register
> foo.bar() if package A is installed at the time package B is
> installed.  If package A is installed after package B, then warn the
> user when package B is loaded and/or attached, so they can re-install
> A and have foo.bar() registered correctly.
>
> I could figure out a way to do this manually, but doubt it would be
> CRAN-approved.  What is the recommended way to handle this situation?
> I've received one suggestion to split B into 2 packages: one without
> the method, and one with.  Are there other alternatives?
>
> Thanks,
> Josh
>
> --
> Joshua Ulrich  |  about.me/joshuaulrich
> FOSS Trading  |  www.fosstrading.com
> R/Finance 2018 | www.rinfinance.com
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Conditionally register method with generic in other package

[Hadley Wickham]

On Thu, Dec 7, 2017 at 2:44 AM, Bill Denney  wrote:
>
>> On Dec 6, 2017, at 07:45, Joshua Ulrich  wrote:
>>
>> To avoid excessive dependencies, I would like to only register
>> foo.bar() if package A is installed at the time package B is
>> installed.  If package A is installed after package B, then warn the
>> user when package B is loaded and/or attached, so they can re-install
>> A and have foo.bar() registered correctly.
>
> One simple solution would be to wrap the instantiation of foo.bar in a 
> require test:
>
> if (require(A)) {
>   foo.bar <- function(...) {
> print("To be or not to be")
>   }
> } else {
>   message("To use the foo.bar function, please install package A.")
> }

I don't think that will work because the code will be executed at
build time, not package-load time.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] tibbles are not data frames

[Hadley Wickham]

> If that is right -- and I tend to believe it is right -- this change had
> better been done in R core and not on package level. I think the root of
> this evil is design inconsistencies of the language together with the lack
> of removing these inconsistencies. The longer we hesitated, the more
> packages such a change could break. The lack of addressing issues in R core
> drives people to try to solve issues on package level. But now we have two
> conflicting standards, i.e. a fork-within-the-language: Am I a member of the
> tidyverse or not? Am I writing a package for the tidyverse or for standard-R
> or for both. With a fork-of-the-language we would at least have a majority
> vote for one of the two and only the fitter would survive. But with a
> fork-within-the-language 'R' gets more and more complex, and working with it
> more and more difficult. There is not only the tidyverse, also the Rcppverse
> and I don't know how many other verses. If there is no extinction of
> inconsistencies in R, not sufficient evolution in R, but lots of evolution
> in Julia, evolution will extinct R together with all its foobarverses in
> favor of Julia (or Python). May be that's a good thing.

I think you are making a slippery slope argument, and I'm not sure I
buy it. I am quite aware of the danger of introducing additional
inconsistencies, and do it very selectively, only when I'm convinced
that the pain is worth it.

> I think tibble should respect drop=TRUE and respect the work of all package
> authors who wrote defensive code and explicitly passed drop= instead of
> relying on the (wrong) default

We'll consider for the next major release:
https://github.com/tidyverse/tibble/issues/311

> . Again: better would be a long-term clean-up
> roadmap of R itself and one simple standard called 'data.frame'. Instead of
> forking or betting on any particular foobarverse: why not have direct
> democratic votes about certain critical features of such a long-term roadmap
> in such a big community?

I'm not sure that democracy works for programming language design.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] tibbles are not data frames

[Hadley Wickham]

On Tue, Sep 26, 2017 at 12:15 PM, Patrick Perry  wrote:
> Pro ignoring x[,1,drop=TRUE]:
> (1) it forces users to write consistent code for extracting a vector from a
> data frame
>
> Con:
> (1) functions that accept both matrices and data frames might break
> (x[[j]][i] doesn't work for a matrix)

I generally think that it's better to keep matrices and data frame
completely separate, but point taken.

> (2) functions that use the access pattern x[i,j,drop = TRUE] will break

This seems pretty rare, and I don't think anyone has complained about it yet.

I don't love adding support for drop = TRUE because it makes [.tibble
type-unstable, but maybe it's reasonable to do so in order to slightly
improve backward compatibility. I've filed an issue so we consider it
for the next major release:
https://github.com/tidyverse/tibble/issues/311

> Perhaps a bigger issue with tibbles is that they don't let you index with
> row names:
>
>> y <- tibble(x = letters)
>> rownames(y)
>  [1] "1"  "2"  "3"  "4"  "5"  "6"  "7"  "8"  "9"  "10" "11" "12" "13" "14"
> "15"
> [16] "16" "17" "18" "19" "20" "21" "22" "23" "24" "25" "26"
>> y[rownames(y)[c(1,5,9,15,21)],]
> # A tibble: 5 x 1
>   x
>   
> 1  
> 2  
> 3  
> 4  
> 5  

I'd argue that this is not as big as an issue, as I have no
recollection of anyone complaining about it.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] tibbles are not data frames

[Hadley Wickham]

> I for one am happy this discussion pops up, because it's a piece of
> information I give to my students as well: convert to a data.frame when you
> start your analysis just to play safe. And this discussion shows why that is
> -for the time being!- a good advice. The moment tibbles become the default
> data format in R, or some R++, or in Julia for all I care, I'll be more than
> happy to burn that drop = FALSE on a stake. But for now we can't ignore the
> differences and the potential for conflicts when you try to use a tibble
> instead of a data.frame.

I think this is sub-optimal advice because most functions do work fine
with tibbles. It is only a few packages (largely written some time
ago) that don't. And typically, if they don't work with tibbles,
you'll get a (usually slightly confusing) error message because some
function will get a data frame instead of a vector. So as far I can
tell, you only need to as.data.frame() retrospectively, not
prospectively. Are you aware of any code that returns an incorrect
result (i.e. no error) when given a tibble instead of a data frame?

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] tibbles are not data frames

[Hadley Wickham]

On Tue, Sep 26, 2017 at 9:22 AM, Patrick Perry  wrote:
> Would it be possible to change tibbles so that
>
> x[,1,drop=TRUE]
>
> returns a vector, not a data frame? I certainly find it surprising that
> tibbles ignore
> the drop argument. If tibbles respeced the drop argument, then package
> developers could rely on
>
> x[,1,drop=FALSE]
>
> or
>
> x[,1,drop=TRUE]
>
> behaving consistently, regardless of whether the argument is a tibble or a
> data.frame.

They can currently rely on x[[1]] returning alway a vector and x[, 1,
drop = FALSE] always returning a data frame whether x is a tibble or a
data frame. I personally don't believe that an additional approach
would help.

> Alternatively, would it be possible to make is.data.frame return FALSE for a
> tibble? Then
> developers that want base-R data.frame behavior can do
>
> if (!is.data.frame(x)) {
> x <- as.data.frame(x)
> }
>

As I've said elsewhere in the thread that would effectively render
tibbles useless because they wouldn't work with many functions.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] tibbles are not data frames

[Hadley Wickham]

On Tue, Sep 26, 2017 at 8:35 AM, Joris Meys  wrote:
> Where its parent class _sometimes_ returns an atomic vector and
>>
>> _sometimes_ returns a data frame.
>
> Indeed. And a tibble doesn't, so there's a conflict. Nobody said data.frame
> works better than tibble. Actually, we all agree that the legacy behaviour
> sucks. But it exists, and causes conflicts when users expect a tibble to
> behave the same as a data.frame.
>
> It does not.

So we should never try and improve upon legacy behaviour? I don't
understand what you're arguing for here. If a tibble didn't inherit
from a data frame, it would be useless.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] tibbles are not data frames

[Hadley Wickham]

On Tue, Sep 26, 2017 at 2:30 AM, Göran Broström  wrote:
> I am beginning to get complaints from users of my CRAN packages (especially
> 'eha') to the effect that they get error messages like "Error: Unsupported
> use of matrix or array for column indexing".
>
> It turns out that they are sticking in tibbles into functions that expect
> data frames as input. And I am using the kind of subsetting that Hadley
> dislikes (eha is an old package, much older than tibbles). It is of course a
> simple matter to change the code so it handles both data frames and tibbles
> correctly, but this affects many functions, and it will take some time. And
> when the next guy introduces 'troubles' as an improvement of 'tibbles', I
> will have to rewrite the code again.

Changing df[, x] to df[[x]] is not very hard and makes your code
easier to understand because it more clearly conveys the intent that
you want a single column.

> While I like Hadley's way of doing it, I think it is a mistake to let a
> tibble also be of class data frame. To me it is a matter of inheritance and
> backwards compability: A tibble should add nice things to a data frame, not
> change basic behaviour, in order to call itself a data frame.
>
> Is it correct to let a tibble be of class "data.frame"?

If it not inherit from data frame, it would be not work with the 99%
of functions that work with data frames and don't deliberately take
advantage of the dropping behaviour of [. In other words, it would be
pointless.

I decided to make [.tibble type-stable (i.e. always return a data
frame) because this behaviour causes substantial problems in real data
analysis code. I did it understanding that it would cause some package
developers frustration, but I think it's better for a handful of
package maintainers to be frustrated than hundreds of users creating
dangerous code.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] tibbles are not data frames

[Hadley Wickham]

On Tue, Sep 26, 2017 at 8:28 AM, Jeroen Ooms  wrote:
> On Tue, Sep 26, 2017 at 11:56 AM, Gábor Csárdi  wrote:
>>
>> On Tue, Sep 26, 2017 at 10:35 AM, Joris Meys  wrote:
>> > I don't like the dropping of dimensions either. That doesn't change the
>> > fact that a tibble reacts different from a data.frame. So tibbles do not
>> > inherit correctly from the class data.frame, and it can thus be argued that
>> > it's against OOP paradigms to pretend tibbles inherit from the class
>> > data.frame.
>>
>> I have yet to see an OOP system in which a subclass cannot override the 
>> methods
>> of its superclass. Not only is this in line with OOP paradigms, it is
>> actually one of the essential OOP features.
>
> Not if this compromises type safety. Formal OOP languages enforce the
> signature matches when you override a method. The fact that R is
> dynamically typed puts this responsibility at the developer. The fact
> that tibble [ returns a data frame where it's parent class returns an
> atomic vector violates this principle, resulting in the obvious type
> errors where tibbles are used as data frames.

Where its parent class _sometimes_ returns an atomic vector and
_sometimes_ returns a data frame.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Referring to data in R/sysdata.rda

[Hadley Wickham]

Just ignore it.
Hadley

On Friday, April 14, 2017, Roy Mendelssohn - NOAA Federal <
roy.mendelss...@noaa.gov> wrote:

> In my package I have a dataframe that I use but want to hide from the
> user.  In Hadley's book on R Packages,  he says:
>
> >   • If you want to store parsed data, but not make it available to
> the user, put it in R/sysdata.rda. This is the best place to put data that
> your functions need.
> >
>
> I have done that,  and sure enough when the package is loaded, the
> structure is there.  However,  when I am working on debugging code, and I
> refer to the  structure in a function,  RStudio gives a warning that the
> structure is out of scope, say the data frame is myDF:
>
> myFunc  <-  function(myIndex) {
>  junk  <-  myDF[index]
> return(junk)
> }
>
> RStudio will warn that myDF is out of scope.  My question is if there is a
> proper way to refer to myDF so as not to get the warning,  or just ignore
> it.  Basically before submission I try to remove all warnings from the
> editor,  even style ones,  just to have things cleaner.
>
> Thanks,
>
> -Roy
>
>
>
>
>
> **
> **
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> ***Note new street address***
> 110 McAllister Way
> Santa Cruz, CA 95060
> Phone: (831)-420-3666
> Fax: (831) 420-3980
> e-mail: roy.mendelss...@noaa.gov  www:
> http://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK
> Jr.
>
> __
> R-package-devel@r-project.org  mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

[[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] .bib file in vignette not found during R CMD check

[Hadley Wickham]

I wonder if it would be useful for R CMD build to list the files it
ignores? A misspecified .Rbuildignore seems to be reasonable for a
high proportion of weird errors where you have no idea what's going
wrong.

Hadley

On Tue, Feb 28, 2017 at 11:57 AM, Duncan Murdoch
 wrote:
> On 28/02/2017 10:44 AM, Patrick Schratz wrote:
>>
>> When building the vignette using R CMD Build or
>> `devtools::build_vignette()` everything works fine.
>>
>> However, during R CMD check I get the following
>>
>> ** checking running R code from vignettes ...*
>> *   ‘sperrorest-vignette.Rmd’ using ‘UTF-8’ ... OK*
>> * NONE*
>> ** checking re-building of vignette outputs ... WARNING*
>> *Error in re-building vignettes:*
>> *  ...*
>> *pandoc-citeproc: Could not find Biblio.bib*
>> *CallStack (from HasCallStack):*
>> *  error, called at src/Text/CSL/Pandoc.hs:224:39 in
>> pandoc-citeproc-0.10.4.1-EdjBizYp62fCPHef3CymGR:Text.CSL.Pandoc*
>> *pandoc: Error running filter /usr/local/bin/pandoc-citeproc*
>> *Filter returned error status 1*
>> *Error: processing vignette 'sperrorest-vignette.Rmd' failed with
>> diagnostics:*
>> *pandoc document conversion failed with error 83*
>> *Execution halted*
>>
>> The .bib file is lying in `/vignettes`. There is a similar question on SO
>>
>> 
>> but
>> the answer does not address the problem.
>> When using full paths everything is fine. However, I cannot use full paths
>> when submitting to CRAN.
>>
>> If you want to check on your own, please use the `dev` branch;
>> https://github.com/pat-s/sperrorest/tree/dev
>>
>> pandoc-citeproc: stable 0.10.4.1 (bottled), HEAD
>> pandoc: stable 1.19.2.1 (bottled), HEAD
>
>
> Your .Rbuildignore file says not to include Biblio.bib.  Don't do that.
>
> Duncan Murdoch
>
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] R CMD Check: Tests running infinite

[Hadley Wickham]

>> A lot of packages have to work around this:
>> https://github.com/search?q=user%3Acran+R_TESTS=Code
>
> I wonder if those are mostly there because of cut'n'paste behavior.

It's not something I've ever advocated; I didn't realise there were so
many people unsetting it. (devtools does it for you)

>> Most of these use testthat, but not all of them.
>
> My interest in this issue is because I haven't yet experienced this
> myself and I run lots and lots of package tests in future that
> utilizes the parallel package.  In doFuture I do similar tests, which
> is on top of the foreach package.   I don't use testthat and I also
> don't use doParallel in my testing.

The motivation for unsetting in in devtools is to avoid problems when
you run R CMD check from inside another R CMD check. I think it
affects some behaviour deep inside R, not just fancy quoting.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Understanding notes from win-builder

[Hadley Wickham]

On Mon, Oct 3, 2016 at 12:10 PM, Roy Mendelssohn - NOAA Federal
 wrote:
> Hi All:
>
> I am working on preparing a package for submission to CRAN, so using devtools 
> i submitted the package to win-builder.  I really appreciate that this has 
> been setup, so that hopefully any final submission will be smooth.  
> win-builder returned three notes, and I am unclear on them in the sense of 
> not certain what I should do to resolve them so hopefully there will  be no 
> notes on submission.  The first one is:
>
>> The Title field starts with the package name.
>> The Title field should be in title case, current version then in title case:
>> 'xtractomatic: An R package for accessing environmental data'
>> 'Xtractomatic: An R Package for Accessing Environmental Data'
>>
>
> the package name is "xtractomatic", but is the last line what is preferred in 
> the DESCRIPTION file?

On CRAN (and in other locations), packages are listed as
"package_name: package_title", which in your case would lead to:

xtractomatic: xtractomatic: An R package for accessing environmental data

So you need to first eliminate "xtractomatic" from the title.  CRAN
generally also considers "an R package" to be obvious from the context
so you also need to remove that. That leaves you with "Accessing
Environmental Data" and suggests you might want to be a bit more
specific.

> The other two notes are essentially the same:
>
>> * checking examples ...
>> ** running examples for arch 'i386' ... [87s] NOTE
>> Examples with CPU or elapsed time > 10s
>>user system elapsed
>> xtracto3.29   0.81   36.49
>> xtracto_3D 3.14   0.64   31.40
>> xtractogon 0.92   0.20   10.73
>> ** running examples for arch 'x64' ... [104s] NOTE
>> Examples with CPU or elapsed time > 10s
>>user system elapsed
>> xtracto2.83   0.64   43.68
>> xtracto_3D 2.58   0.72   43.60
>>
>
> I assume the problem here is the amount of time to run the examples.  The 
> problem is that what this package does is download data from a remote server, 
> and times can vary a lot on the examples.  Is this a show stopper when I 
> submit to CRAN?  I can try to simplify the examples to cut down on the time.  
> Alternatively, will it help to include this in the cram-comments.md file?

You can use \donttest{} to tell CRAN to not run it as part of their
automated tests.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [Learning] the secret of Win[dows C-backed packages]

[Hadley Wickham]

One other option is to include the src for libmagic inside your
package, and use that as a fallback if it's not installed on the
system. That gives linux users what they want (linking to the system
package), and windows users what they want (it just works). It only
works for simple libraries, but it looks like libmagic might qualify.

I could have sworn I did that in a package, but I can't remember which one :(

Hadley

On Sat, Aug 13, 2016 at 11:34 AM, Bob Rudis  wrote:
> Hey folks,
>
> I usually stare in awe at the C-backed packages that rely on eternal
> libraries which are super-easy to get working on macOS & *nix _but_ that
> also work perfectly on Windows. I fire up Windows (*maybe*) once a month to
> test some of my packages but I'm curious as to what I need to do to setup a
> more extended toolchain to create libraries such as are found in
> https://github.com/rwinlib.
>
> Jeroen (I think others, too) seem to effortlessly package those up and I
> fully grok his "anticonf" setup and the 32-bit & 64-bit Windows library
> setup. I just can't seem to actually do the building.
>
> Why I'm asking what I'm asking (below) is that I'm working on something for
> the $DAYJOB now - https://github.com/hrbrmstr/wand - that requires libmagic
> and I kinda, unfortunately, actually need it to also work on Windows (it
> usually doesn't matter, but this time some folks who use Windows systems at
> work need to use this forthcoming package).
>
> Rather than b[eu]g Jeroen or others for library building/packaging, I'd be
> very, keenly interested in learning what else besides Rtools I need to
> install to be able to make similar binary bundles to include during
> installation (and to have my compiled pkgs work on Windows).
>
> My disdain for Windows and my frustration with the super-limited toolchain
> components installed with Rtools is probably contributing to my inability
> to solve this on my own (no bash.exe...rly?). I used to use cygwin back in
> the day but there are so many cautions in the main R docs abt compatible
> versions that I'd rather not spend hours or days figuring out something
> that others already have.
>
> One example here is that I actually managed to get one of the libmagic
> support packages (the regex library) built and installed on Windows (in the
> toolchain /usr/local) but can't get libmagic's `configure` script to
> find/use it.
>
> I'm more than willing to write up any copious pointers folks provide into a
> detailed, attributed blog post or R Journal article since this is seriously
> the only bit holding me back from working on and releasing a ton of other
> compilation-required packages to CRAN. I also know I'm not the only one who
> gets stalled when trying to get similar things (especially those with full
> Boost dependencies) to work on Windows.
>
> thx,
>
> -Bob
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Absent variables and tibble

[Hadley Wickham]

The other thing you need to be aware of it you're using the other
approach is partial matching:

df <- data.frame(xyz = 1)
is.null(df$x)
#> [1] FALSE

Duncan - I think that argues for including a has_name() (hasName() ?)
function in base R. Is that something you'd consider?

Hadley

On Mon, Jun 27, 2016 at 10:05 AM, Lenth, Russell V
<russell-le...@uiowa.edu> wrote:
> Thanks, Hadley. I do understand why you'd want more careful checking.
>
> If you're going to provide a variable-existing function, may I suggest a 
> short name like 'has'? I.e., has(x, var) returns TRUE if x has var in it.
>
> Thanks
>
> Russ
>
>> On Jun 27, 2016, at 9:47 AM, Hadley Wickham <h.wick...@gmail.com> wrote:
>>
>> On Mon, Jun 27, 2016 at 9:03 AM, Duncan Murdoch
>> <murdoch.dun...@gmail.com> wrote:
>>> On 27/06/2016 9:22 AM, Lenth, Russell V wrote:
>>>>
>>>> My package 'lsmeans' is now suddenly broken because of a new provision in
>>>> the 'tibble' package (loaded by 'dplyr' 0.5.0), whereby the "[[" and "$"
>>>> methods for 'tbl_df' objects - as documented - throw an error if a variable
>>>> is not found.
>>>>
>>>> The problem is that my code uses tests like this:
>>>>
>>>>if (is.null (x$var)) {...}
>>>>
>>>> to see whether 'x' has a variable 'var'. Obviously, I can work around this
>>>> using
>>>>
>>>>if (!("var" %in% names(x))) {...}
>>>>
>>>> but (a) I like the first version better, in terms of the code being
>>>> understandable; and (b) isn't there a long history whereby we can expect a
>>>> NULL result when accessing an absent member of a list (and hence a
>>>> data.frame)? (c) the code base for 'lsmeans' has about 50 instances of such
>>>> tests.
>>>>
>>>> Anyway, I wonder if a lot of other package developers test for absent
>>>> variables in that first way; if so, they too are in for a rude awakening if
>>>> their users provide a tbl_df instead of a data.frame. And what is 
>>>> considered
>>>> the best practice for testing absence of a list member? Apparently, not
>>>> either of the above; and because of (c), I want to do these many tedious
>>>> corrections only once.
>>>>
>>>> Thanks for any light you can shed.
>>>
>>>
>>> This is why CRAN asks that people test reverse dependencies.
>>
>> Which we did do - the problem is that this is actually caused by a
>> recursive reverse dependency (lsmeans -> dplyr -> tibble), and we
>> didn't correctly anticipate how much pain this would cause.
>>
>>> I think the most defensive thing you can do is to write a small function
>>>
>>> name_missing <- function(x, name)
>>>!(name %in% names(x))
>>>
>>> and use name_missing(x, "var") in your tests.  (Pick your own name to make
>>> your code understandable if you don't like my choice.)
>>>
>>> You could suggest to the tibble maintainers that they add a function like
>>> this.
>>
>> We're definitely going to add this.
>>
>> And I think we'll make df[["var"]] return NULL too, so at least
>> there's one easy way to opt out.
>>
>> The motivation for this change was that returning NULL + recycling
>> rules means it's very easy for errors to silently propagate. But I
>> think this approach might be somewhat too aggressive - I hadn't
>> considered that people use `is.null()` to check for missing columns.
>>
>> We'll try and get an update to tibble out soon after useR.  Thoughts
>> on what we should do are greatly appreciated.
>>
>> Hadley
>>
>> --
>> http://hadley.nz



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Absent variables and tibble

[Hadley Wickham]

On Mon, Jun 27, 2016 at 9:03 AM, Duncan Murdoch
 wrote:
> On 27/06/2016 9:22 AM, Lenth, Russell V wrote:
>>
>> My package 'lsmeans' is now suddenly broken because of a new provision in
>> the 'tibble' package (loaded by 'dplyr' 0.5.0), whereby the "[[" and "$"
>> methods for 'tbl_df' objects - as documented - throw an error if a variable
>> is not found.
>>
>> The problem is that my code uses tests like this:
>>
>> if (is.null (x$var)) {...}
>>
>> to see whether 'x' has a variable 'var'. Obviously, I can work around this
>> using
>>
>> if (!("var" %in% names(x))) {...}
>>
>> but (a) I like the first version better, in terms of the code being
>> understandable; and (b) isn't there a long history whereby we can expect a
>> NULL result when accessing an absent member of a list (and hence a
>> data.frame)? (c) the code base for 'lsmeans' has about 50 instances of such
>> tests.
>>
>> Anyway, I wonder if a lot of other package developers test for absent
>> variables in that first way; if so, they too are in for a rude awakening if
>> their users provide a tbl_df instead of a data.frame. And what is considered
>> the best practice for testing absence of a list member? Apparently, not
>> either of the above; and because of (c), I want to do these many tedious
>> corrections only once.
>>
>> Thanks for any light you can shed.
>
>
> This is why CRAN asks that people test reverse dependencies.

Which we did do - the problem is that this is actually caused by a
recursive reverse dependency (lsmeans -> dplyr -> tibble), and we
didn't correctly anticipate how much pain this would cause.

> I think the most defensive thing you can do is to write a small function
>
> name_missing <- function(x, name)
> !(name %in% names(x))
>
> and use name_missing(x, "var") in your tests.  (Pick your own name to make
> your code understandable if you don't like my choice.)
>
> You could suggest to the tibble maintainers that they add a function like
> this.

We're definitely going to add this.

And I think we'll make df[["var"]] return NULL too, so at least
there's one easy way to opt out.

The motivation for this change was that returning NULL + recycling
rules means it's very easy for errors to silently propagate. But I
think this approach might be somewhat too aggressive - I hadn't
considered that people use `is.null()` to check for missing columns.

We'll try and get an update to tibble out soon after useR.  Thoughts
on what we should do are greatly appreciated.

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] modification of warning messages

[Hadley Wickham]

Try warningcall(R_NilValue, "message")

Hadley

On Wednesday, June 22, 2016, Aaron King  wrote:

> I am in the midst of trying to improve error and warning messages in a
> complex package.  I find myself wanting to modify R's default behavior when
> printing warnings.  Specifically, it frequently happens for me that the
> call that is printed with the warning message is not informative.  When the
> warning arises in R code, I have the ability to suppress the printing of
> the call by setting 'call.=FALSE'.  However, when the warning arises in C
> code (via the 'warning()' function), I have no such option.
>
> 'tryCatch' and 'withCallingHandlers' are of no use (or at least, if they
> are, I haven't figured out how).
>
> Consider the following simple example:
>
> Contents of file 'example.c':
> --
> #include 
>
> void example (int *x) {
>   if (*x>0)
> error("ouch");
>   else if (*x<0) {
> warning("duck!");
> *x = 22;
>   } else {
> *x = 11;
>   }
> }
> --
>
> Compile and load the C code:
> --
> system2(R.home("bin/R"),args=c("CMD","SHLIB","example.c"))
> dyn.load(paste0("example",.Platform$dynlib.ext))
> --
>
> The function 'f' calls 'example' as defined above.  On an error, it
> modifies the error message using 'tryCatch'.
> --
> f <- function (x) {
> y <- tryCatch(
> .C("example",x=as.integer(x))$x,
> error = function (e) {
> stop("in f: ",conditionMessage(e),call.=FALSE)
> }
> )
> y
> }
> --
>
> Get an error:
>
> > f(1)
> Error: in f: ouch!
>
> Get a warning:
>
> > f(-1)
> [1] 22
> Warning message:
> In doTryCatch(return(expr), name, parentenv, handler) : duck!
>
> It's the fact that 'doTryCatch(return(expr), name, parentenv, handler)' is
> meaningless to the user that bothers me.  How can I modify the warning?
>
> Thanks in advance for any insight.
>
> --
> Professor Aaron A. King
> Ecology & Evolutionary Biology
> Mathematics
> Center for the Study of Complex Systems
> University of Michigan
> GPG Public Key: 0x15780975
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org  mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
http://hadley.nz

[[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] Getting a package ready for CRAN - some questions

[Hadley Wickham]

On Mon, May 30, 2016 at 7:10 PM, Roy Mendelssohn - NOAA Federal
 wrote:
> Hi All:
>
> I am in the midst of some minor revisions to my xtractomatic package, which 
> up till now has only been on github.  Since ncdf4 for Windows is now 
> available from CRAN  (and many thanks to whomever is responsible for that) I 
> thought I would try to get it into CRAN.  Some questions:
>
> 1.  The vignette uses a lot of packages that the main code does not - I put 
> those in the DESCRIPTION file, under  “Suggests”, is this correct?

Yes.

> 2. The vignette uses ggfortify, which was in CRAN for 3.2.x, but is not in 
> CRAN for 3.3.x.  Do I assume then that a submission will fail, or will the 
> submission work but just without the vignette?  Or can I include in the 
> vignette the command to install from github  (using devtools), and then that 
> will build?

You definitely do not want to install packages when running a vignette.

Given that ggfortify has been archived
(https://cran.r-project.org/web/packages/ggfortify/index.html), I'd
recommend using a different package (maybe broom?).

> 3. On a remote build, my vignette is likely to fail to build.  That is 
> because the vignette downloads a large amount of data in many requests, and 
> if for any reason any one of the downloads fail or times out, the vignette 
> build will fail.  As above, will this cause the entire submission to fail, or 
> just the vignette to fail?  And is there anyway to provide a pre-built 
> vignette in the submission?

You shouldn't be downloading data in a vignette. Can you make a
separate data package that just bundles the data?

Hadley

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Roxygen help documenting a S4 class

[Hadley Wickham]

Does this help?

code <- c("BeginningBal", "Convexity", "EffConvexity", "EffDuration",
"EndingBal",
  "Formula", "Horizon", "HorizonReturn", "KeyRateConvexity", "KeyRateDuration",
  "KeyRateTenor", "ModDuration", "Name", "PassThroughInterest", "Period",
  "PmtDate", "PrepaidPrin", "SMM", "ScheduledPrin", "ShiftType", "Shiftbps",
  "SpreadToInterCurve", "TimePeriod", "TotalCashFlow", "Type", "WAL",
  "YieldToMaturity", "forwardrate", "spotrate")

docs <- c("BeginningBal", "Convexity", "EffDuration", "EndingBal",
"Formula", "Horizon",
"KeyConvexity", "KeyRateDuration", "KeyRateTenor", "ModDuration", "Name",
"PassThroughInterest", "Period", "PmtDate", "PrepaidPrin", "SMM",
"ScheduledPrin", "ShiftType", "Shiftbps", "SpreadToInterCurve", "TimePeriod",
"TotalCashFlow", "Type", "WAL", "YieldToMaturity", "forwardrate", "spotrate" )


setdiff(code, docs)
setdiff(docs, code)

Hadley

On Fri, Apr 22, 2016 at 10:31 AM, Glenn Schultz  wrote:
> All,
>
> Below are two classes that I have created Scenario and Mtg.Scenario.
>
> Mtg.Scenario contains Scenario when I run check I get the following warning.
>
> I have gone through my book R Packages and looked at the EPub writing 
> extension but I cannot find an example.
>
> Any help is appreciated
> Glenn
>
> * checking for code/documentation mismatches ... WARNING
> S4 class codoc mismatches from documentation object 'Mtg.Scenario-class':
> Slots for class 'Mtg.Scenario'
>  Code: BeginningBal Convexity EffConvexity EffDuration EndingBal
>Formula Horizon HorizonReturn KeyRateConvexity KeyRateDuration
>KeyRateTenor ModDuration Name PassThroughInterest Period
>PmtDate PrepaidPrin SMM ScheduledPrin ShiftType Shiftbps
>SpreadToInterCurve TimePeriod TotalCashFlow Type WAL
>YieldToMaturity forwardrate spotrate
>  Inherited: Name Type Horizon ShiftType Shiftbps Formula
>  Docs: BeginningBal Convexity EffDuration EndingBal Formula Horizon
>KeyConvexity KeyRateDuration KeyRateTenor ModDuration Name
>PassThroughInterest Period PmtDate PrepaidPrin SMM
>ScheduledPrin ShiftType Shiftbps SpreadToInterCurve TimePeriod
>TotalCashFlow Type WAL YieldToMaturity forwardrate spotrate
>
>
>
>  #' An S4 Class representing scenario analysis details
>  #'
>  #' The class Scenario is the representation of the
>  #' scenario run by the investor
>  #' @slot Name A character the name of the scenario
>  #' @slot Type A character the type of the scenario
>  #' @slot Horizon A character the time horizon over which the
>  #' scenario is run
>  #' @slot ShiftType A character the interest rate shift type (e.g.
>  #' twist, parallel, bull flatten, or bull steepen)
>  #' @slot Shiftbps A numeric value the scenario shift in basis points
>  #' @slot Formula A function represnting the shift which applied to the term 
> structure
>  #' @exportClass Scenario
>  setClass("Scenario",
> representation(
>   Name = "character",
>   Type = "character",
>   Horizon = "character",
>   ShiftType = "character",
>   Shiftbps = "numeric",
>   Formula = "function"
> ))
>
>  #' An S4 Class representing the results of mortgage return scenario analysis
>  #'
>  #' The class Mtg. Scenario holds the results of a scenario analysis run
>  #' @slot Period A numeric value the period number forward from current
>  #' @slot PmtDate A character the payment date on which the cashflow is 
> expected to be received
>  #' @slot TimePeriod A numeric value the period stated as a unit of time
>  #' @slot BeginningBal A numeric value the forecasted beginning balance in 
> the period
>  #' @slot PassThroughInterest A numeric value the interest paid through to 
> the investor
>  #' @slot ScheduledPrin A numeric value the scheduled principal due in the 
> period
>  #' @slot PrepaidPrin A numeric value the forecasted prepaid principal in the 
> period
>  #' @slot EndingBal A numeric value the forecasted ending balance in the 
> period
>  #' @slot TotalCashFlow A numeric value the forecasted total cashflow 
> received by
>  #' the investor in the period
>  #' @slot spotrate A numeric vector the spot rate curve
>  #' @slot forwardrate A numeric vector the forward rate curve
>  #' @slot SMM A numeric vector the forecasted SMM vector
>  #' @slot YieldToMaturity A numeric value the scenario yield to maturity
>  #' @slot WAL A numeric value the scenario weighted average life
>  #' @slot SpreadToInterCurve A numeric value the spread to the interpolated 
> curve
>  #' @slot ModDuration A numeric value the scenario modified duration
>  #' @slot Convexity A numeric value the scenario convexity
>  #' @slot EffDuration A numeric value the effective duration which is the sum 
> of the
>  #' key rate durations
>  #' @slot KeyRateTenor A numeric vector the key rate tenors
>  #' @slot KeyRateDuration A numeric vector the duration of each key rate tenor
>  #' @slot KeyConvexity A numeric vector the convexity of 

Re: [R-pkg-devel] Documenting S4 generic does not show usage

[Hadley Wickham]

1. Depends on whether you're documenting the method or the generic.
2. You don't
3. I can never remember. I think if it's your generic, you only need
it in one place.

Hadley

On Mon, Mar 21, 2016 at 11:06 AM, Manny Calavera <olbapj...@gmail.com> wrote:
> Thank you so much, it works like a charm :-)
>
> I would appreciate if you could please answer (very briefly) questions 1 to
> 3, so I can learn how to correctly document S4 generics properly in the
> future.
>
> Thanks again.
>
> 2016-03-18 15:11 GMT+01:00 Hadley Wickham <h.wick...@gmail.com>:
>>
>> The problem seems to be your use of methods::setMethod instead of
>> setMethod (etc). Roxygen2 doesn't seem to be quite smart enough to
>> realise that these aren't equivalent. You might want to file an issue
>> on github so I look into this the next time I'm working on roxygen2.
>>
>> Hadley
>>
>> On Fri, Mar 18, 2016 at 7:20 AM, Manny Calavera <olbapj...@gmail.com>
>> wrote:
>> > Good day to everyone,
>> > I have an issue when documenting an S4 generic. I have the following in
>> > my
>> > file generics.R:
>> >
>> > #' @rdname myfunction-methods#' @name myfunction <- without this,
>> > roxygen2 complaints about missing name#' @export
>> > methods::setGeneric("myfunction",
>> >   function( arg1, arg2 ),
>> >   arg3, arg4 {
>> > methods::standardGeneric("myfunction")});
>> >
>> > and then in my file mymethods.R:
>> >
>> > #' Something#'#' A brief description#'#' @param all params... #'
>> > @return Something#' @name myfunction <- without this, roxygen2
>> > complaints on missing name#' @include generics.R#' @rdname
>> > myfunction-methods#' @export
>> > methods::setMethod( "myfunction",
>> >   methods::signature( arg1 = "formula", arg2 = "data.frame" ),
>> >   function( arg1, arg2, arg3, arg4 ) {
>> >
>> >...whatever
>> > })
>> >
>> > With this, everything is fine except that the usage section is not
>> > showing
>> > up. Could you please correct what is wrong in my documentation? More
>> > precisely:
>> >
>> >1.
>> >
>> >Is it correct to write the documentation before setMethod or is it
>> >preferably before setGeneric ?
>> >2.
>> >
>> >Why do I need the @name in both files? Should it be different? Does
>> > it
>> >matter?
>> >3.
>> >
>> >Do I need @export in both files?
>> >4.
>> >
>> >Would @alias help at all?
>> >
>> > I tried reading Hadley Wickham's section on how to document S4 functions
>> > but did not help (probably I didn't understand something correctly).
>> >
>> > Thank you very much in advance.
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > __
>> > R-package-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>>
>>
>> --
>> http://hadley.nz
>
>



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] S3 length method behavior

[Hadley Wickham]

I've found that it's a very bad idea to provide length or names
methods for just this reason.
Hadley

On Sat, Jan 30, 2016 at 1:25 PM, Nathan Wendt  wrote:
> Hello,
>
> I have run into an issue while developing an R package. Specifically, my
> issue relates to what happens when I define an S3 length method for my
> class. Here is my basic setup:
>
> # Here is the structure of myClass
> # uses an externalptr to operate on file using some C functions
> list(file = "my/file/location", handle = )
>
> # this function gets an S3Method() in NAMESPACE
> length.myClass <- function(x) {
>   .Call("get_class_length",myPkg)
> }
>
> As you can see, myClass is just a list of two pieces of information about
> the particular object. Without a defined length method, length(myClass)
> would be 2. However, I defined a length method to give me the information
> about the amount of binary messages contained in the file the object points
> to. In one of my test files there are 82 messages and length(myObject)
> correctly returns 82. What I ran into is that I was crashing RStudio when
> rebuilding my package with an object of myClass in my environment. Only
> removing my S3 length method caused the crash to not occur. After looking
> for memory leaks and other errors I finally noticed that the str() on the
> object of myClass looked odd. It returned something like this:
>
> List of 82
>  $ file  : chr "my/file/location"
>  $ handle:
>  $ NA:
> Error in object[[i]] : subscript out of bounds
>
> It seems that when I define an S3 method for length that somehow the object
> of myClass then gets restructured to have the length returned by the
> function. There are 82 messages in the file, but myClass objects should
> only have two elements. My best guess here is that the RStudio crash was
> happening because the object was misrepresented internally. Of course, I
> cannot be sure. None of my tests pointed to anything useful.
>
> My questions are, then, whether this behavior makes sense and what to do
> about it. If I define my own str() method, will that fix it? I think I am
> just misunderstanding what is going on with the methods I have defined.
> Hopefully, someone can offer some clarity.
>
> Thanks,
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://had.co.nz/

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] RCMD Note - why did I have to do this?

[Hadley Wickham]

You didn't include the NOTE you saw, and this isn't valid roxygen:

#' @imports methods::fields

So it's a bit hard to tell what the problem is.

Hadley


On Sun, Dec 20, 2015 at 12:02 PM, Glenn Schultz  wrote:
> Hello all,
>
> I need some help understanding namespace and methods.
>
> I received a note from RCMD imports methods fields...
>
> I changed my file from
> #' @import methods
> NULL
>  to include the following:
>
> #' @imports methods::fields
> NULL
>
> such that it now reads
>
> #' @import methods
> NULL
>
> #' @imports methods::fields
> NULL
>
> This removed the note - I am not just sure why I had to do this - I use
> devtools and Roxygen
>
> Thanks,
> Glenn
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://had.co.nz/

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] S3 method, useMethod and <-, using Roxygen

[Hadley Wickham]

Here's a minimal reprex:

out <- roc_proc_text(rd_roclet(), "
  #' Foo
  `foo<-` <- function(x, y, value) {
UseMethod('set_labels<-')
  }

  #' Foo
  `foo<-.default` <- function(x, y, value) {
x
  }
  ")[[2]]

cat(format(out))

That generates

\usage{
\method{foo}{default}(x, y) <- value
}

which I believe is correct, although I don't think I've ever seen such
a construct in the wild.

Duncan: does that look right to you? (i.e. is that what the usage of
method of a replacement function should look like?)

Hadley

On Fri, Oct 23, 2015 at 3:30 AM, Daniel Lüdecke  wrote:
> Hello,
> I don't exactly know how to name my problem, so I try to describe it.
>
> In my package (sjmisc), I have a function to set label attributes to
> vectors:
>
> set_labels <- function(x, labels, ...) {
> ...
> }
>
> Usage would be:
> x <- set_labels(x, c("lo", "high"))
>
>
> No I wanted to also add functionality to directly change a value:
> set_labels(x) <- c("lo", "high")
>
>
> So I added this to my package source:
>
> #' @rdname set_labels
> #' @export
> `set_labels<-` <- function(x, force.labels = FALSE, force.values = TRUE,
> value) {
>   UseMethod("set_labels<-")
> }
>
> #' @rdname set_labels
> #' @export
> `set_labels<-.default` <- function(x, force.labels = FALSE, force.values =
> TRUE, value) {
>   x <- set_labels(x, values, force.labels, force.values)
>   x
> }
>
>
> However, running the check gives following note and warnings:
>
> * checking R code for possible problems ... NOTE
> set_labels<-.default: no visible binding for global variable 'values'
> * checking Rd files ... OK
> * checking Rd metadata ... OK
> * checking Rd line widths ... OK
> * checking Rd cross-references ... OK
> * checking for missing documentation entries ... OK
> * checking for code/documentation mismatches ... WARNING
> Functions or methods with usage in documentation object 'set_labels' but not
> in code:
>   set_labels.default
>
> * checking Rd \usage sections ... WARNING
> Objects in \usage without \alias in documentation object 'set_labels':
>   'set_labels.default'
>
> Bad \usage lines found in documentation object 'set_labels':
> <- value
>
> Functions with \usage entries need to have the appropriate \alias
> entries, and all their arguments documented.
> The \usage entries must correspond to syntactically valid R code.
> See chapter 'Writing R documentation files' in the 'Writing R
> Extensions' manual.
>
>
> I don't know what to do here. Any help is appreciated!
>
> Thanks in advance
> Daniel
> --
>
> _
>
> Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen
> Rechts; Gerichtsstand: Hamburg | www.uke.de
> Vorstandsmitglieder: Prof. Dr. Burkhard Göke (Vorsitzender), Prof. Dr. Dr.
> Uwe Koch-Gromus, Joachim Prölß, Rainer Schoppik
> _
>
> SAVE PAPER - THINK BEFORE PRINTING
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://had.co.nz/

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] how to make r-release-osx-x86_64-mavericks machine support rgl 3D plots

[Hadley Wickham]

 | Check DetailsVersion: 1.8.3
 | Check: tests
 | Result: ERROR
 | Running the tests in ‘tests/stdUsage.R’ failed.
 | Last 13 lines of output:
 |   plot(ffTest42,col=Col,plot_GOF=TRUE,speed=T)
 |  [1] compute goodness-of-fit with leave-one-out k-nearest 
 neighbor(guassian kernel), kknn package
 |  
 |   #if ever needed, k-nearest neighbor parameters for goodness-of-fit 
 can be access through convolute_ff
 |   #a new fit will be calculated and added to forstFloor object as 
 ffTest42$FCfit
 |   ffTest42 = 
 convolute_ff(ffTest42,userArgs.kknn=alist(kernel=epanechnikov,kmax=5))
 |   plot(ffTest42,col=Col,plot_GOF=TRUE)
 |  
 |   #in 3D the interaction between X3 and X reveals itself completely
 |   
 show3d(ffTest42,3:4,col=Col,plot.rgl=list(size=5),sortByImportance=FALSE)
 |  Error in rgl.open(useNULL) : rgl.open failed
 |  Calls: show3d ... plot3d.default - next3d - .check3d - open3d - 
 rgl.open
 |  Execution halted
 | Flavor: r-release-osx-x86_64-mavericks


 Yes, I see lots of that on Linux too as the tests run 'headless' without a
 controlling terminal.

 A while ago I added support in rgl to run on headless machines.  Set the
 environment variable RGL_USE_NULL=TRUE before loading rgl, and should
 never try to call X11 (or whatever graphics system you're using).
 (It's also possible to use options(rgl.useNULL = TRUE) within R.  That's
 no help to you, but is useful when embedding rgl plots in knitr documents.)

Oh that's great! I have a related problem to Dirk - except I run R CMD
check on my local machine, so while the checks are running, RGL
windows randomly pop up over the course of hours.

Hadley

-- 
http://had.co.nz/

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Working with connections

[Hadley Wickham]

Also it's a little strange to put an RDS file _inside_ a gz, since
normally the compression is done internally.

And are you sure you should be exposing this data via a function,
rather than using the regular package data mechanism?

Hadley

On Sun, Aug 9, 2015 at 7:04 AM, Joshua Ulrich josh.m.ulr...@gmail.com wrote:
 On Sun, Aug 9, 2015 at 8:59 AM, Glenn Schultz glennmschu...@me.com wrote:
 Hi All,

 I use connections to open and close data folders needed by my package.
 After each function closes I get the following warnings (depending on the
 connection that has been opened).

 10: closing unused connection 3
 (/Library/Frameworks/R.framework/Versions/3.2/Resources/library/BondLab/BondData/bondlabMBS4.rds)

 Below is the connection function that is related to the above warning:

 #
   #' A connection function to BondData calling MBS cusps
   #'
   #' Opens a connection to the BondData folder to call MBS cusip data
   #' @param MBS.id A character string the MBS.id or cusip number current
 MBS.id is supported
   #' @export
   MBS - function(MBS.id = character){
   MBS.Conn - gzfile(description = paste(system.file(package
 = BondLab),
   /BondData/, MBS.id, .rds, sep = ), open
 = rb)
   MBS - readRDS(MBS.Conn)
   return(MBS)
   close.connection(MBS.Conn)
   }

 I have googled this warning and it seems to be triggered when a function
 terminates and the connection is open.  But, I think the connection function
 closes the connection once the object is returned.  What am I doing wrong?

 Your call to return() exits the function, so the close.connection()
 call is never evaluated.  Considering using on.exit() to close the
 connection, since it will close the connection regardless of how the
 function exits (e.g. because of an error).

 -Glenn
 __
 R-package-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-package-devel



 --
 Joshua Ulrich  |  about.me/joshuaulrich
 FOSS Trading  |  www.fosstrading.com

 __
 R-package-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
http://had.co.nz/

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel