Use of DESCRIPTION for anything besides package development

Package development
,
1

With each package comes a DESCRIPTION file describing what the package does, what version it is in, authors, ...

For a package, the structure of this file is well documentated, although it can be extended (for instance, devtools handles remotes repository when installing a package).

We can see another use of the DESCRIPTION file with shiny applications.

I find this file very useful because it let the user now when the project was last use, who are the maintainer and authors, and more importantly what version it is in.

There could be other applications which can use this file besides packages and shiny applications. For example, markdown document could have their own (although some informations would be redondant), but also webservices.

Would you find useful to use a DESCRIPTION file with all sorts of project (basically every project using a version control system) ? If not, how do you manage the different versions of your projects (comments in a header, releases in git, ...) ?

2

Personally, I think DESCRIPTION is a good place for meta-information about your project. If your project is internal, then you can add custom fields, as you like (well, mostly, some fields are interpreted specially by devtools, etc. of course).

If you want to put the package on CRAN, then the fields you can use are somewhat restricted, but e.g. Config/* fields are allowed AFAICT.

3 Likes