Submit to CRAN

[Robinlovelace]

This package is very, very useful. Yet it is not very visible to users. I think getting on CRAN will make it way more useful. The fact it has external dependencies that may not be installed on CRAN servers should not be a barrier, as outlined here: https://github.com/r-spatial/discuss/issues/41#issuecomment-706334208

I'm happy to run some tests to see what happens after running

devtools::check_win_devel()

will also help us with our work updating Geocomputation with R to use more modern and effective packages.

[paleolimbot]

Sorry to leave this hanging for two days...I'm totally fine with a CRAN submission but I think there are a few issues that need to be addressed before any particular release (of qgisprocess) can be considered "stable". That said, I think maintaining this particular CRAN package will not be hard because it can't run any actual tests (because QGIS is not installed). I think I'd still prefer users to install this via remotes::install_github() for now because new users will get the latest fix (and #36 will be a big fix).

Happy to debate this list, but in my head these are the things that need to happen before there is any particular release of qgisprocess that can be considered "stable":

• [ ] Use the JSON interface to qgisprocess where available
• [ ] Fix the spaces in file path bug on Windows (upstream in processx)
• [ ] After the JSON thing is done, add support for all qgis input types
• [x] stars package suport for rasters

[Robinlovelace]

Apologies for the slow response to me. I discussed this issue yesterday with @jannes-m and @nowosad in relation to the 2nd edition of Geocomputation with R, which we plan to publish at some point in 2022, likely spring or summer, and it would be great if the package were on CRAN by then. Good news: we're happy to help with that effort although unsure which bits you need help with. Regarding your list, I guess the file paths one is the most important. The others I would see as 'nice to have'. My thinking is that having it on CRAN will open up this amazing package to a wide range of people and therefore encourage further development. Agree #36 looks like a big one...

[paleolimbot]

I agree that this should happen soon...I'm giving a talk on this at FOSS4G and I think that will be a good time to get a round of feedback, after which a CRAN submission seems in order.

One thing I didn't realize is that there is no way to use JSON as input yet. I flagged Nyall already, but this feature is important for getting things to work smoothly on Windows and to support all the input types. That said, I think I can fix the WKT2 thing by working around the .bat file (and will do so before FOSS4G). I'd also like to properly use the JSON output before FOSS4G since it's now available in almost everybody's installed QGIS version.

Something that would help me out would be to generate a bunch of minimal test cases for all the input types. Like...find simple algorithms that have an input type and write a test_that("input type XX works", {...}) block that passes. I imagine that will help you generate some opinions about how various R objects can be serialized to make the experience a bit more seamless (for example, st_bbox() objects have a pretty straightforward translation to what QGIS expects a bbox to look like). No pressure if you don't get to it!

[Robinlovelace]

Something that would help me out would be to generate a bunch of minimal test cases for all the input types. Like...find simple algorithms that have an input type and write a test_that("input type XX works", {...}) block that passes. I imagine that will help you generate some opinions about how various R objects can be serialized to make the experience a bit more seamless (for example, st_bbox() objects have a pretty straightforward translation to what QGIS expects a bbox to look like). No pressure if you don't get to it!

That definitely sounds like something I can can help with and I imagine Jannes will be keen to get involved in the effort too. Worth creating a separate issue on it? Happy to be assigned on that.

[paleolimbot]

Use #13!

[jannes-m]

I am happy to help, of course! But before doing so, I plan to finally finish writing the vignette(s) (#31). I plan to do so within the next 2 to 3 weeks.

[florisvdh]

Updating Dewey's checklist:

• [X] Use the JSON interface to qgisprocess where available
• [X] Fix the spaces in file path bug on Windows (upstream in processx)
• [x] After the JSON thing is done, add support for all qgis input types (#13)
• [x] stars package suport for rasters

I'm not sure where we are with https://github.com/paleolimbot/qgisprocess/issues/13, but to be checked further; probably supporting JSON-input-only for some cases, and preferably tests are added to check the support for different QGIS inputs.

Proposing remaining steps wrt CRAN submission:

• Internals:
  • [x] check support for all qgis input types
  • [ ] add argument assertions in all exported functions, using assert_that()
  • [ ] check and update consistent usage of assert_qgis()
  • [ ] increase code coverage
• Exported functions:
  • [x] revise choice between exported vs internal functions (my feeling is that not all current exported functions are meant for direct use by users)
  • [x] revise function name choices. E.g. 'use_json_output' sounds as a command (do that) but only informs about a config state.
• Documentation:
  • [x] add vignettes (#2, PR #31)
  • [x] document functions more consistently
  • [x] update README (introduction)
  • [x] further improve pkgdown reference (e.g. making use of function families to create subtitles)
• Organisational:
  • [x] perhaps link this package with r-spatial, or flag as such / move it there
  • [x] create NEWS.md, bump package version
  • [x] submit to CRAN

[florisvdh]

Dewey and I had a brief meeting today.

• we discussed #2, #13, #133, #134, in which Dewey gave advice from his experience as a many-package-maintainer. Conclusions, further comments and decisions, or implementation of remaining steps will happen there.
• I have accepted to continue maintenance and am prepared to become package maintainer (and continue my learning curve!)
• We want to transfer the repo to r-spatial, where it would fit well.
• Once #13, #133, #134 and some smal things wrt functions are done (cf. previous comments), the functions are ready for a first CRAN release 0.1.0. Before that, I will look into the amount of work needed wrt documentation and propose/take a decision wrt documentation work to be done before releasing 0.1.0 (after which further elaborated documentation is still possible, e.g. in 0.2.0).

As always, further ideas are most welcome!

[florisvdh]

I'm in the stage of anticipating CRAN notes before submitting, based mainly on advice in r-pkgs.org & usethis.

@paleolimbot @JanCaha @jannes-m for CRAN submission we should add a copyright holder (cph). This should be a legal entity. I propose to add my employer INBO here, since I am allowed to also invest some personnel time for maintaining and improving. Do you agree?

Consequently, INBO is also package funder (fnd) because of this personnel time. If other funders are to be added, please shoot (similar may apply to former or current employer of @paleolimbot?)

[JanCaha]

Sure, no problem ;)

[jannes-m]

Yeah, go for it.

[paleolimbot]

Go for it! No need to add my employer as a copyright holder.

[florisvdh]

Great, thanks for the quick responses.

[florisvdh]

BTW, I have also included affiliations in DESCRIPTION for Dewey (Voltron Data) and myself.

https://github.com/r-spatial/qgisprocess/blob/c9c9f4c639111c94640c28e82642b1a569a5e7c1/DESCRIPTION#L5-L8

If I should add this for more people, let me know! Affiliations appear in CITATION.cff on GitHub and also in the foreseen Zenodo publication, when hovering above the author names (example).

[florisvdh]

https://cloud.r-project.org/package=qgisprocess :slightly_smiling_face:

[Robinlovelace]

Amazing!