Writing R code in a DCF is unappealing

[hadley]

Since you don't get syntax highlighting, help, autocomplete, ...

What do you think about supporting some additional way of defining custom linters that uses a file with a .R extension?

[AshesITR]

Not sure about the .R extension. Most IDEs allow you to configure the default language per extension, and that makes it easy to confuse the config with an actual (productive) script within the project.

Other packages tend to use yaml for configs, PyCharms language injection allows for R syntax highlighting and autocompletion to be used. Plus, YAML is quite close to DCF, to the point that interpreting our .lintr as a YAML file works too:

[AshesITR]

Rather minimal changes to the .lintr file would make it parseable R code, though. I'd be okay with allowing .lintr to also (in addition to being dcf-formatted) be parseable R code, restricted to assigning the lintr config variables, i.e., for our .lintr

linters <- linters_with_defaults( # The following TODOs are part of an effort to have {lintr} lint-free (#584)
   line_length_linter = line_length_linter(120),
   # TODO add implicit_integer_linter()
   cyclocomp_linter = cyclocomp_linter(37), # TODO reduce to 15
)
exclusions <- list(
  "inst/doc/creating_linters.R" = 1,
  "inst/example/bad.R",
  "tests/testthat/default_linter_testcode.R",
  "tests/testthat/dummy_packages",
  "tests/testthat/dummy_projects",
  "tests/testthat/exclusions-test",
  "tests/testthat/knitr_formats",
  "tests/testthat/knitr_malformed"
)

@MichaelChirico WDYT?

[hadley]

Allowing .lintr to be either DCF or R doesn't seem that appealing to me either. I was thinking more of something like _lintr.R

There's some related art in Roxygen2 — you can configure simple options in DESCRIPTION or provide man/roxygen/meta.R if you want to run R code.

[AshesITR]

Not a big fan of allowing two separate configuration files - what to do if both files exist in the same directory?
pkgdown, blogdown, covr and GitHub Actions use YAML for configuration, by the way. I've never heard of the man/roxygen/meta.R feature.

I must admit though, that the DCF format took a bit to get used to, especially the akward indentation requirements.

[hadley]

The easiest solution is to error if both files are present.

If you find the idea of a .R file unpalatable, I think yaml would also work, but you'd need to put some thought into how to parameterise it so that fewer configs would need to include executable R code.

[AshesITR]

Hmm that seems hard because we intend on linters being configured via linters_with_defaults() or linters_with_tags().
For a transitional period, I'd be fine if .lintr would be parsed as YAML and, if that fails, as DCF with a deprecation warning.
I guess the question is, can we avoid R code by leveraging the YAML structure, e.g. using

linters:
 - with: defaults
   line_length_linter:
     length: 120
   cyclocomp_linter:
     limit: 37
exclusions:
 - inst/doc/creating_linters.R: 1
 - inst/example/bad.R
 - tests/testthat/default_linter_testcode.R
 - tests/testthat/dummy_packages
 - tests/testthat/dummy_projects
 - tests/testthat/exclusions-test
 - tests/testthat/knitr_formats
 - tests/testthat/knitr_malformed

[MichaelChirico]

I also find the DCF approach a bit awkward... what's the appeal of it besides back-compatibility?

[AshesITR]

The only other advantage I can think of is read.dcf() is in base R.

[MichaelChirico]

the R-based approach just needs source() though? maybe I'm not understanding how the R approach is intended to work, exactly

[AshesITR]

Yeah, right. If we want to use R as the "format".
I was comparing to YAML.
We could do something like evalq(source(".lintr", encoding = ??, local = TRUE), envir = new.env(parent = ??)) for R.
But we should definitely check for non-expected settings generated in the env.

[MichaelChirico]

right... that basically maps to the current setup though right? DCF keys/values --> variable names/values in config environment

[AshesITR]

True. But in R code it's more tempting to define other variables.

[hadley]

If you were worried about that you could inspect the environment and error if there were unexpected variables.

PS. I'd suggest sys.source(".lintr", env = new.env(baseenv())) instead of using source()
PPS. I'd also suggest using _lintr.R or similar instead of reusing the existing file name

[MichaelChirico]

if we're going to switch we could also offer a script (maybe a snippet in NEWS) to convert an existing DCF->R

[MichaelChirico]

I guess this would supersede #886