Submit package to CRAN

[karthik]

It would be great to get this package to CRAN at some point soon.

• Deal with the license issue. MIT + License file is now required by the CRAN maintainers.
• Write unit tests with testthat
• Write documentation with roxygen2
• Change URL and bugreports URL in the DESCRIPTION file.
• Add Travis integration and shield to README
• Write a vignette
• Write a blogpost for rOpenSci

Minor nuisances:

• Remove .Rhistory files from repo.

[karthik]

Also

• Remove dependencies

[sckott]

what do you mean by remove dependencies?

[karthik]

what do you mean by remove dependencies?

When I ported the package over there were several packages listed under Depends.
here

[sckott]

Ah yes

[msund]

Hey @karthik and @sckott, it was great to see you both this weekend.

Adding in @xsaintmleux and @mkcor here (who I think you both met). To follow-up on our talk, we'd love to get Plotly on CRAN and would love your help doing so. What needs to happen and what should be next steps?

Thanks a bunch for your help and including us in the package. We're excited about this one. cc @chriddyp.

[sckott]

Hey @msund - nice to see you at useR! - I'm finishing up some consulting work this week, but will give some feedback early next week

[msund]

Hey @sckott, we'd love to get started on this if we can. Happy to have a video call too if you'd like, depending on the complexity of the topic. Thanks so much for the help. Sidebar: I am terribly sorry to bug.

[sckott]

Hey @msund , No worries, happy to help.

To submit to CRAN, i'd suggest using devtools package. With devtools, you can easily:

• Check: Make sure the pkg passes R CMD CHECK using the function check(). Some warning's are okay (let me know if you have questions), but errors definitely need to be fixed. You should run check() on both current R version (3.1.1) and the development version (you can get from here for mac http://r.research.att.com/)
• Examples: If the examples in your documentation files are within \dontrun{} you don't need to worry, but if they aren't then you should make sure they work with run_examples() It's good idea to make sure examples work anyway, even if they won't be run during CRAN's check of your package.
• Tests: check() will run tests as long as you aren't ignoring tests explicitly, but you can check tests separately by doing test_package()
• Check windows: I imagine you're all on mac or at least linux machines. If so, check that windows version builds with build_win(). This will submit the package to a windows machine that will build and run check, then send email to person listed as maintainer with output (that's Chris)
• Reverse dependencies: I imagine you don't have to worry about this yet, but if there are any packages on CRAN that import/depend on this package, run revdep_check() is your friend and will download and check that those pkg work with your current version of the package.
• Send to CRAN: When you're ready, use release(), which will actually run check again, then ask you a number of questions to make sure you've remembered to do everything, then it will compose and open an email in your default browser and upload the pkg via ftp (or I think now does throw the cran web form)

Don't hesitate to ask any questions.

It's easiest if the person listed as the maintainer (Chris) submits the package from his email address (the same one listed in the DESCRIPTION file), but not required. Someone from CRAN core team will reply either saying its up on cran, or you have things to fix.

[msund]

@sckott, you're the best, thanks.

[TrigonaMinima]

Is anyone doing this? I'd like to write the vignettes.

[cpsievert]

@TrigonaMinima we'll be submitting to CRAN this week (see #296). Feel free to start a pull request with additions/edits to vignettes/