Release qgisprocess 0.1.0

[florisvdh]

First release:

• usethis::use_cran_comments()
• Update (aspirational) install instructions in README
• Proofread Title: and Description:
• Check that all exported functions have @return and @examples
• Check that Authors@R: includes a copyright holder (role 'cph')
• Check licensing of included files
• Review https://github.com/DavisVaughan/extrachecks

Prepare for release:

• git pull
• urlchecker::url_check()
• devtools::build_readme()
• devtools::check(remote = TRUE, manual = TRUE)
• devtools::check_win_devel()
• devtools::check_rhub() (as recommended by devtools::release()) But see #167 (comment) below. (~ rhub::check_for_cran(), recommended by r-pkgs.org)
• git push
• Draft blog post

Submit to CRAN:

• usethis::use_version('minor')
• devtools::submit_cran() better (recommended in devtools docs): devtools::release() (has extra checks)
• Approve email

Wait for CRAN...

• Accepted 🎉
• Add preemptive link to blog post in pkgdown news menu
• usethis::use_github_release()
• usethis::use_dev_version(push = TRUE)
• Finish blog post
• Toot

[ambarja]

@florisvdh maybe add to this the publication of the cheatsheet in Posit 😅

[florisvdh]

@ambarja this was just the automatically generated issue by usethis::use_release_issue(). When do you expect the cheatsheet to be ready? If all goes well, I may make a first CRAN submission tomorrow (it may still include updated cheatsheet PNGs if you have them, say 14:00 UTC tomorrow). After that, I'm not online for at least a week. Then handling feedback from CRAN (CRAN may use short deadlines) – during that stage, at least if resubmission is needed, we could still update the URLs to the cheatsheet PDFs if you would already have them accepted and published at Posit at that time.

I don't regard the Posit publication step as essential for the CRAN release since currently the PDFs from your repo are referred, which is fine! Replacing by Posit URLs for the PDFs can still happen in a next release. Perhaps Posit prefers publishing contributed cheatsheets when a package is already on CRAN.

Oh yes, for the CRAN release it would be best to have the installation instructions in the cheatsheet updated to install.packages("qgisprocess"), at least in a branch of your repo. But there's no problem IMO if this would only be updated in a next CRAN release cycle.

[ambarja]

Excellent, I'm looking forward to the release of CRAN, to update a few things, certainly an excellent job. ^^

[florisvdh]

R CMD check results on win-builder (R-devel on Windows Server 2022): https://win-builder.r-project.org/0QQnEpJEZPOH/00check.log

The R-hub service seems to be stalled today; a few days ago results were quite OK so will probably skip this step. I cannot even access the results from those earlier logs anymore.

[florisvdh]

First CRAN submission from 20 July (dca0284 -> current 45834ea) yielded below comments; will be tackled in an upcoming PR.

Comments on submission 01

Please write references in the description of the DESCRIPTION file in the form
authors (year) https://docs.qgis.org/latest/en/docs/user_manual/processing_algs/.

Please add \value to .Rd files regarding exported methods and explain the functions results in the documentation. Please write about the structure of the output (class) and also what the output means. (If a function does not return a value, please document that too, e.g. \value{No return value, called for side effects} or similar)
Missing Rd-tags:
as_qgis_argument.Rd: \value
qgisprocess-deprecated.Rd: \value

"Using foo:::f instead of foo::f allows access to unexported objects. This is generally not recommended, as the semantics of unexported objects may be changed by the package author in routine maintenance."
Used ::: in documentation:
man/as_qgis_argument.Rd:
qgisprocess:::as_qgis_argument(c("a", "b"), spec = qgisprocess:::qgis_argument_spec(qgis_type = "range"), use_json_input = FALSE)
man/as_qgis_argument.Rd:
qgisprocess:::as_qgis_argument(c(1, 2), spec = qgisprocess:::qgis_argument_spec(qgis_type = "range"), use_json_input = FALSE)
man/as_qgis_argument.Rd:
qgisprocess:::as_qgis_argument(c("a", "b"), spec = qgisprocess:::qgis_argument_spec(qgis_type = "range"), use_json_input = TRUE)
man/as_qgis_argument.Rd:
qgisprocess:::as_qgis_argument(c(1, 2), spec = qgisprocess:::qgis_argument_spec(qgis_type = "range"), use_json_input = TRUE)
man/as_qgis_argument.Rd:
qgisprocess:::as_qgis_argument(mat, spec = qgisprocess:::qgis_argument_spec(qgis_type = "matrix"), use_json_input = FALSE)
man/as_qgis_argument.Rd:
qgisprocess:::as_qgis_argument(mat, spec = qgisprocess:::qgis_argument_spec(qgis_type = "matrix"), use_json_inpu [... truncated]
Please omit one colon.

You have examples for unexported functions. Please either omit these examples or export these functions.
Examples for unexported function
qgis_detect_macos_paths() in:
st_as_sf.Rd
qgis_enable_plugins() in:
st_as_stars.Rd

Please ensure that your functions do not write by default or in your examples/vignettes/tests in the user's home filespace (including the package directory and getwd()). This is not allowed by CRAN policies. Please omit any default path in writing functions. In your examples/vignettes/tests you can write to tempdir().

You are setting options(warn=-1) in your function. This is not allowed. Please rather use suppressWarnings() if really needed.
-> tests/testthat/test-qgisprocess-deprecated.R

Please do not modify the global environment (e.g. by using <<-) in your functions. This is not allowed by the CRAN policies.
-> R/zzz.R

Please fix and resubmit.

[florisvdh]

Settling on below statements for locally triggered CRAN-like pre-testing before submitting:

devtools::check(remote = TRUE, manual = TRUE) # Ubuntu 64-bit, R-release. 
                                                                # To replicate behaviour on a fresh system, remove
                                                                # qgisprocess cache and add 'document = FALSE'.
devtools::check_win_devel()
devtools::check_rhub(platforms = "windows-x86_64-devel")
devtools::check_rhub(platforms = "fedora-clang-devel") # may abort during testing, maybe due to long time of compiling R packages

Best run these statements in separate R sessions = parallel. Best run them in fresh terminal R sessions (outside RStudio) to avoid any preloading actions by RStudio 😣.

devtools::check_rhub() by default runs (currently) on following subset of rhub::platforms():

fedora-clang-devel:
  Fedora Linux, R-devel, clang, gfortran
ubuntu-gcc-release:
  Ubuntu Linux 20.04.1 LTS, R-release, GCC
windows-x86_64-devel:
  Windows Server 2022, R-devel, 64 bit

However specifying single ones results in the output being streamed.

However note that R-devel on R-hub is much older (months) than on win-builder and GitHub Actions (see next post).

I take the win-builder NOTES as 'official' for usage in cran-comments.md, although I use English-language counterparts (it uses German language).

Below notes in Windows on R-hub are bugs in R-hub (r-hub/rhub#503, r-hub/rhub#560) and can be ignored:

❯ checking for non-standard things in the check directory ... NOTE
  Found the following files/directories:
    ''NULL''

❯ checking for detritus in the temp directory ... NOTE
  Found the following files/directories:
    'lastMiKTeXException'

Below note in Fedora on R-hub is a bug in R-hub (r-hub/rhub#548) and can be ignored:

❯ checking HTML version of manual ... NOTE
  Skipping checking HTML validation: no command 'tidy' found

[florisvdh]

CRAN resubmission today (a56abb3) resulted in an automated feedback from automated win-builder pretests on Debian and Windows. On Debian (not on Windows), the below WARNING appeared. Strangely enough this never popped up before in other systems, also not during the first CRAN submission.

* checking Rd \usage sections ... WARNING
Documented arguments not in \usage in documentation object ‘as_qgis_argument’:
  ‘.use_json_input’

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.

The warning should be simple to solve, but the involved 'feature' is present several months already.

Note: I could not reproduce this on R-hub's debian-clang-devel platform. But the R version may be at stake for that: R Under development (unstable) (2023-06-09 r84528) in R-hub (same as Fedora), R Under development (unstable) (2023-08-10 r84931) in the CRAN-pretest on Debian. Anyway, the Windows CRAN pretest uses the same R-devel version as CRAN pre-testing, as do the GitHub Actions.

[florisvdh]

CRAN submission from 11 August (18e5dc6) yielded below comments; to be tackled in an upcoming PR.

Comments on submission 03

we still see examples for unexported functions. Please either omit these examples or export these functions.
Examples for unexported function
qgis_detect_macos_paths() in:
st_as_sf.Rd
qgis_enable_plugins() in:
st_as_stars.Rd

You have examples wrapped in if(FALSE). Please never do that. Ideally find toy examples that can be regularly executed and checked. Lengthy examples (> 5 sec), can be wrapped in \donttest{}, unexecuteable in \dontrun{}.
-> qgis_unconfigure.Rd, qgis_configure.Rd

Please always make sure to reset to user's options(), working directory or par() after you changed it in examples and vignettes and demos. -> inst/doc/qgis_expressions.R
e.g.:
oldpar <- par(mar = rep(0.1, 4))
...
par(oldpar)

Please fix and resubmit.

[florisvdh]

CRAN landing page: https://cran.r-project.org/package=qgisprocess

[paleolimbot]

Epic!

[jannes-m]

Excellent, indeed! Great work @florisvdh!

[florisvdh]

Thanks! Has been spread on Mastodon (((and on Twitter/X))).

[florisvdh]

Strangely I do not see a Windows binary for r-release on CRAN, while it has been created for r-devel and r-oldrel. Maybe that's still to come, although packages more recently published have all of them. 🤔

[florisvdh]

not see a Windows binary for r-release

Has resolved automatically, just needed more time.