4 ms·

Sure, if you want to get a billion issues reported that are caused by outdated versions of the linters.

• oefrha 6y ago
  Outdated version could simply be counted as nonexistent, then a new version would be installed "as needed".
  • hobofan 6y ago
    And then you'd need to figure out how to install that new version side-by-side with the existing one, or otherwise you will upgrade and break the existing setup of a lot of people. That is also not always trivial, especially if you have an existing setup like e.g. system python + pyenv managed python. Should the linters then be installed via the system package manager? How would you handle that across many different platforms? And now you multiply all that effort by the number of linters you are packaging, because almost none of them share a common toolchain. It just opens a whole box of problems, that do nothing to actually further the tool you are building.
    • oefrha 6y ago
      The "install as needed" linters of course should live in their own separate universe, not scattered everywhere. Alternatively you ask people to install linters themselves, and refuse to run if they're outdated. Language X devs likely already have reasonably up-to-date language X linters installed, or know how to install them anyway. A lot of effort: probably. Many different platforms: there are three platforms that carry any weight. See GitHub Actions runner environments. Docker on the dev machines is easy for the project, but (1) performance is subpar on macOS and Windows due to virtualization; (2) it also gets outdated; (3) the image is easily gone if you like pruning, then you need to pull the image all over again. (Thankfully the image isn't huge, ~380MB at the moment.)
    • jakeogh 6y ago
      Portage solved all that long ago. Parallel versions are called slots.