search

ropensci / rrrpkg

Use of an R package to facilitate reproducible research
255 stars 25 forks source link

DESCRIPTION should be mandatory? #2

Open hadley opened 9 years ago

hadley commented 9 years ago

Because it includes machine readable information about:

gaborcsardi commented 9 years ago

Definitely. Without DESCRIPTION it is not a package, anyway. :)

benmarwick commented 9 years ago

Right, for a package yes, for a research compendium, perhaps not. Perhaps we should clarify it a bit with this?

An optional DESCRIPTION file describes the software dependencies of the compendia. When a DESCRIPTION file is included along with the other items above, then the compendium is also a formal R package and you can take advantage of many time-saving tools for package development, testing and sharing.

hadley commented 9 years ago

It's ok for a compendia not to be a package, but surely it's highly desirable to have machine readable metadata about authors, licensing etc?

jennybc commented 9 years ago

I also see the value in collecting the list of package dependencies, including versions. Although this bit of info in DESCRIPTION could easily get out of date for a project where the package infrastructure was being used mostly as the inspiration for file organization, i.e. no regular use of R CMD check.

benmarwick commented 9 years ago

I've seen people putting some of that metadata in a README, in an unstructured way. But perhaps this is a point to push for a bit more standardisation. How about something like this, removing 'optional'?

A DESCRIPTION file that gives structured, machine-readable information about the authors, licensing, the software dependencies and other metadata of the compendium. When a DESCRIPTION file is included along with the other items above, then the compendium is also a formal R package and you can take advantage of many time-saving tools for package development, testing and sharing.

ablack3 commented 2 years ago

The OHDSI community has been using R packages to implement studies for a while and has many such studies in https://github.com/ohdsi-studies. Personally speaking I think the package structure is not the best fit for all studies. The analyst has to be willing to use the debugger to find code errors and step through execution. I find myself working inside a development version of a study package while actually calling functions in the installed version. We have recently started using renv to record dependencies of a study which is great but could conflict with package dependencies in the DESCRIPTION file. We also have the study metadata in structured readme files and the DESCRIPTION file is sometimes left with boilerplate perhaps because people find it is redundant.