Run namespace_linter in a subprocess? Optionally?

[MichaelChirico]

Note that using check_exports=TRUE or check_nonexports=TRUE will load packages used in user code so it could potentially change the global state.

We could avoid this by running the linter in a subprocess, right? Is it worthwhile to do so?

[renkun-ken]

Is there a standard that how far we could go to change the global state when linting is run? Looks like there could different levels:

1. No global state should be changed.
2. No packages should be loaded except lintr and its dependencies (e.g. xml2, xmlparsedata) itself.
3. Only known packages used in linters are allowed to be loaded, but not attached, e.g. cyclocomp used in cyclocomp_linter.
4. Unknown packages used in user code are allowed to be loaded, but not attached, e.g. namespace_linter.

[AshesITR]

I think if we want to support something like this (which would be nice), we should go and run the entire lint() in a separate process instead of having individual linters spawn child processes.

NB though that checkUsage() sometimes reports false positives if code uses variables declared in other locations (so sometimes I tend to run devtools::load_all() before linting to prevent those false positives)

[MichaelChirico]

That makes sense to me -- maybe we can just add an option to lint(): execute_in_subprocess=FALSE by default. Hopefully there won't be too much overhead to maintain a branch like this.

[AshesITR]

Maybe we can make use of callr::r() for this.
And we should make sure that lint_dir() and lint_package() handle this as well without spawning one process per file.

[AshesITR]

Crossref #240; also interesting for parallelization.