use_project() should create DESCRIPTION?

[hadley]

That way the project can act as a package when needed (i.e. load_all()). But we need some field that specifies this is not a package, and update the checks elsewhere.

[hadley]

Alternatively, load_all() could also look for .here

[jennybc]

Here's how rprojroot recognizes an R package:

https://github.com/krlmlr/rprojroot/blob/0ec8bf7d70b62201a3749f62100481e15b647550/R/has-file.R#L117

What if we made a DESCRIPTION file that used Project: foo instead of Package: usethis as the first line?

I wish I understood when GitHub will inline the code linked to vs. not.

[noamross]

I think promoting DESCRIPTION as the standard metadata for an R project is a good idea, as it provides essential dependency information and it would also help with capturing authorship and other metadata. DESCRIPTION is used for:

• Building containers with project dependencies on mybinder.org (via devtools)
• Installing dependencies on CI systems (usually via devtools)
• Gathering metadata for codemeta.json files and thus will be used for zenodo.org and other repositories.

The question to me is whether Project: foo instead of Package: foo will break any other needed tools.
Codemeta looks for Project but could be quickly updated to use either. @cboettig

[cboettig]

I agree with @noamross that I'd mostly be worried about breaking compatibility with existing tooling if we replace Package: with Project:, since that's a major motivation to using DESCRIPTION in the first place.

• I believe this would break devtools::install() as a way to handle the automated install of the project / compendium thing. Though remotes::install_deps() seems to be happy with this (yay!), so maybe it a not a major issue.

• Looks like this breaks rcmdbuild;:check(). (As you know, you can omit an R/ dir, put .Rmds in vignettes and use check() as a way to check for having both valid DESCRIPTION metadata (Author, license, etc) and that the vignette can be rendered. And can have Travis/Appveyor run these checks with usethis setup without additional monkeying around CI config files. Maybe this setup is a hack but I fits nicely to what I think is a common setup / need for projects.

• Looks like this switch would also cause pkgbuild::build() to fail, though maybe that's okay.

• Breaks pkgdown::build_articles(). (Which is otherwise a nice way to get HTML versions of appendices using a relatively minimal setup).

Not sure I understand the motivation to replace Package. If the goal is to have a marker distinguishing such Projects from recognized packages, why not introduce Project as an optional separate field into DESCRIPTION for this purpose, while preserving the declaration of Package: (and all the magic that comes with that little word)?

[hadley]

@cboettig thanks for the detailed analysis. I agree with your conclusions — there doesn't seem to be much benefit to introducing some sort of special "project" idea that sits partway in between the current conception of a project and a package.