Submit R package to CRAN?

[jhofman]

Let's discuss when we think this would be appropriate and what's required.

[jhofman]

@willdebras, can you run through checks to see how this is looking

we may need to clean up some dangling files in sandbox, etc. and exclude some of the python checks from R build checks

[jhofman]

@willdebras will document things to prep for CRAN submission

[willdebras]

This is in pretty good shape. The primary tasks to getting this into submission shape are resolving any errors, warnings, and notes generated by R CMD Check --as-cran. CRAN will reject for any existing errors or warnings. CRAN will also

The status of this check is as follows:

1 error x | 0 warning x | 4 notes x

• 1 ERROR: Failed tests. I've designated the package to skip the python tests, so this is resolved to 0 errors. From the looks of it, the tests fail because we updated x_encoding domain to be 0:3 instead of 0.5, 2.5 to add more padding. This could be easily resolved on the python end:

  datamations/datamations/datamation_groupby.py

  Line 79 in 120a155

  "domain": [0.5, 2.5]

• 4 Notes

1. checking package dependencies ... NOTE
   Imports includes 25 non-default packages.
   Importing from so many packages makes the package vulnerable to any of
   them becoming unavailable. Move as many as possible to Suggests and
   use conditionally.

• I think this is easily justified given the context of the package. We could submit with this note.

2. checking installed package size ... NOTE
   installed size is 94.4Mb
   sub-directories of 1Mb or more:
   doc 87.8Mb
   htmlwidgets 5.3Mb

• This is a hefty, but I don't think the worst. We can cut down some by getting rid of raw data, sandbox, from main, but I believe this is just heavy because we have a lot of vignettes holding large HTML widgets. We could justify and submit with this and see what happens.

3. checking top-level files ... NOTE
   Non-standard file/directory found at top level:
   'package-lock.json'

• I believe package-lock doesn't need to get bundled in the targz, but I could be wrong. Adding this file to a .Rbuildignore would eliminate this note.

4. checking R code for possible problems ... NOTE
   dmta_group_by: no visible binding for global variable '.'
   dmta_summarize: no visible binding for global variable '.'
   generate_group_by_tooltip: no visible global function definition for
   'one_of'
   Undefined global functions or variables:
   . one_of

• This should be resolved before submission. Namespace declaration for tidyselect::one_of will resolve this note. We may need to remove it for backward compatibility though and check for other newer functions when we run various versions.

Next steps:

1. Might be useful to add a news.md file documenting the state of the package and recent updates. I'm never quite certain if this is necessary or a best practice, but it is usually recommended.
2. After resolving notes (or accepting that they are fine), add a file called cran-comments.md including justification for remaining notes. This is ther ecommendation of r-pkgs.org to ensure we aren't rejected for something that should be fine.
3. Test on various environments. CRAN requires this to work on a couple different platforms. It seems we already have github actions set up to test on different platforms, so I would suggest we resolve any strange errors in the actions check. For submission, we can also run devtools::check_rhub, devtools::check_win_devel, and devtools::check_win_release. We don't need to pass checks on all platforms, but we do need consistent checks across a couple. I am going through these checks today and tomorrow to see where we land and if there is anything I can resolve quickly.

After this, it should be all good to do final checks with devtools::release() and submit.

[jhofman]

strange about the 94mb package and the large docs folder. only shows as 6.6mb installed on my machine.

@willdebras, can you poke around with .libPaths() and see if you can track down why this happens?