Feature list for first version

dirkschumacher commented 7 years ago

The package should help to get up to speed when developing a package. It should contain helper functions to:

[x] create the basic package infrastructure, with a toy example of code including roxygen2 documentation
[x] support for continuous integration tools: travis, appveyor, codecov.io
[x] create a README.Rmd / README.md containing tags for the above, CRAN release status, and basic package information, along the lines of: https://github.com/reconhub/outbreaker2
[x] create a basic vignette template
[x] create a website generated by pkgdown
[x] create a default lintr file
[x] git clone all existing RECON repositories
[x] install all existing RECON packages, either from CRAN (stable versions) or github (devel versions)
[x] ....

It should also help to adhere to the RECON guidelines http://www.repidemicsconsortium.org/resources/guidelines/

`init`

I am currently thinking of having a central init function that guides you through configuring a first package template similar to devtools::release(). If the folder is empty, it could simply create template files like readme/vignette without asking 🤔

This central function relies on small, public helper functions like configuring travis or creating a README.

The init function could do the following:

[x] git initif no git repo (ask?)
[x] Create .Rbuildignore and .gitignore
[x] Create a DESCRIPTION file (ask for package name and license)
[x] Check if the package name is already taken on CRAN
[x] Create a testthat folder
[x] Create a sample R file with roxygen2 code
[x] Create a sample vignette (ask for it)
[x] Create a readme.Rmd
[x] Create travis.yml (ask for it)
[x] Create appveyor file (ask for it)
[x] Create a default .lintr file
[x] Register coverage in travis (ask for it)
[x] Create news file
[x] Run devtools::document()
...

`check`

In addition there could be a checkfunction that performs various checks. Some ideas:

[x] R cmd check
[x] lintr::lint_package
[x] goodpractice::gp
[x] Check if travis/appveyor are setup
[x] Does the DESCRIPTIONcontain a URL/BugTracker URL?
[x] Is there a vignette?
[x] Is roxygen2 being used?
[x] Any @importFrom / importFrom in NAMESPACE?
[x] Is there a docs folder / gh-pages branch? if not, ask the user if he/she has a public documentation page somewhere.
[x] Snake case?
[x] Is there a code of conduct?
[x] Is there a news file?
[x] Are there tests? Test coverage?
...

Other functions:

Install stable RECON packages (how to get a current stable list of packages. Query a repo using github api? 🤔) Maybe use drat (https://github.com/eddelbuettel/drat)

thibautjombart commented 7 years ago

Sounds good to me, most of it! As for stable RECON packages, I guess this would be via the github API indeed: grab the project name, and check if a corresponding page exists on CRAN.

A trickier bit is when it comes to 'functional' packages, i.e. packages which work at least in part, but for some reasons are not on CRAN yet. There's quite a few of them so far. Not sure what criteria to use here. Simplest thing might be for the maintainers to add a file stating it is functional?

dirkschumacher commented 7 years ago

One could use drat (https://github.com/eddelbuettel/drat) and just create a package repository with all RECON packages (that are not on CRAN yet).

thibautjombart commented 7 years ago

I think @richfitz had a pass at that prior to RECON. I think this would indeed be a good approach, though I haven't played with drat myself. @richfitz thoughts?

richfitz commented 7 years ago

I use drat extensively for distributing packages for other work at IDE. It works very well. I think that with r-hub there are some other similar things brewing too (drat is nice from the users point of view but exceedingly bare bones from the developer's point of view - inserting packages is an interactive action divorced from the building of packages, running CI, etc. I have a half-arsed tool for this but there are issues).

Unless it's changed, drat by default creates repos that do not work for windows or OSX users - you have to add empty bin directories. More interestingly, if there are packages that have compiled code in them, getting such packages built to order is hard.

And the final issue to think about is how to decouple/relate the development cycle from the drat release cycle from the CRAN release cycle. In general you don't want to be pushing every commit in there (Thibaut looks like he's already thinking about that above)

dirkschumacher commented 7 years ago

I added a template for the README, based on epicontacts. Is there another good example?

dirkschumacher commented 7 years ago

We could also create a package called reconhub similiar to tidyverse. This imports all stable RECON packages.

I am not sure if installing all recon packages automatically adds so much value. Probably a drat repository with release candidates would make more sense.

thibautjombart commented 7 years ago

Templates for README:

One with no example / demo code: https://github.com/reconhub/outbreaker2

One with (too much) demo code: https://github.com/reconhub/incidence

+1 to a reconhub package. Adds a bit of value - e.g. simplifying requirements for courses or workshop, or as part of a docker image. +1 to drat repo too, though that's a bit of a different thing - maybe too much added work for this project? Your call.

dirkschumacher commented 7 years ago

Added a first version of reconhub (https://github.com/reconhub/reconhub) :) :shipit:

I think a proper drat would require an automated build workflow. Otherwise people need to add their packages in there manually.

dirkschumacher commented 7 years ago

Really not sure about pkgdown. This is currently only available on github. Same with goodpractice. Do you think it adds value to create a pkgdown website automatically? And then, where? gh-pages branch or docs? docs is certainly easier to maintain but can make the package really big.

dirkschumacher commented 7 years ago

I just added a first try to include pkgdown

reconhub / recontools