Currently, runLinter takes a bespoke approach to finding oleans and rebuilding files if they are not found.
This bespoke approach can also lead to unintended behavior: for example, runLinter does not, for example, ensure that the oleans are up to date, meaning that runLinter will run without errors on stale oleans.
If runLinter instead had access to the lake workspace—perhaps if it were implemented as a facet, or a script—then fetching the necessary build artifacts through lake would improve its reliability and simplify the code.
Integrating runLinter with lake could also set us up for other improvements: for example, if non-global environment linters produced a (cached) trace (visible to lake) after succeeding, runLinter could possibly avoid re-linting unchanged files. We could also possibly avoid re-linting for certain global linters in cases where traces indicate the relevant build artifacts haven't changed, should linters be able to specify which visibility level they depend on. (For example, simpNF should not need to be re-run after only changing docstrings.) But possibilities like these are purely hypothetical, and might have certain costs only apparent after exploring them.
This refactor might mean that the "preferred" syntax for calling runLinter might change, but I believe it could be done without a breaking change to the existing syntax (i.e. lake exe runLinter could still be supported).
Currently,
runLintertakes a bespoke approach to finding oleans and rebuilding files if they are not found.This bespoke approach can also lead to unintended behavior: for example,
runLinterdoes not, for example, ensure that the oleans are up to date, meaning thatrunLinterwill run without errors on stale oleans.If
runLinterinstead had access to the lake workspace—perhaps if it were implemented as a facet, or a script—then fetching the necessary build artifacts through lake would improve its reliability and simplify the code.Integrating
runLinterwith lake could also set us up for other improvements: for example, if non-global environment linters produced a (cached) trace (visible to lake) after succeeding,runLintercould possibly avoid re-linting unchanged files. We could also possibly avoid re-linting for certain global linters in cases where traces indicate the relevant build artifacts haven't changed, should linters be able to specify which visibility level they depend on. (For example,simpNFshould not need to be re-run after only changing docstrings.) But possibilities like these are purely hypothetical, and might have certain costs only apparent after exploring them.This refactor might mean that the "preferred" syntax for calling
runLintermight change, but I believe it could be done without a breaking change to the existing syntax (i.e.lake exe runLintercould still be supported).