5 ms·

Hi, there is a local run option with instructions here: https://github.com/github/super-linter/blob/master/docs/run-linter-locally.md https://github.com/github/

Hi, there is a local run option with instructions here: https://github.com/github/super-linter/blob/master/docs/run-linter-locally.md https://github.com/github/super-linter/blob/master/docs/run-...

FalconSensei 6y ago
Have to install docker to run a linter... Nah, thanks.
- GaryNumanVevo 6y ago
  Docker is probably the least annoying solution, would you rather install linters for 40 different languages on your system?
  - ori_b 6y ago
    I'd rather not run a linux VM for this, so yes. It should be possible to isolate it to /opt/github-linter/* on my BSD machines, or put into a nix package. (Also, I guess this is one more reason that docker is a big red flag for 'hastily hacked together unportable software that would be hell to ship.')
    - deleted 6y ago
      [deleted]
    - bastardoperator 6y ago
      Look at the Dockerfile, it's all there. All 143 lines and 2 bash scripts. Are you about to introduce a new BSD ports package?
    - philsnow 6y ago
      I'm 100% fine with running this and similar tools with docker to avoid polluting my machine with dependencies / un-uninstallable cruft and also to allow the people making such tools to concentrate on the tools and not supporting installation on 30 different platforms. Hell, docker even works on windows these days. but your comment made me think of this meme, which I can't not link to https://i.imgflip.com/24ac74.jpg https://i.imgflip.com/24ac74.jpg text for people who don't want to click: It works on my machine Then we'll ship your machine And that is how docker was born
  - oefrha 6y ago
    Install linters as needed / pick up what's already installed could be a feasible option.
    - hobofan 6y ago
      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.)
- deleted 6y ago
  [deleted]
- pensatoio 6y ago
  Installing Docker is so easy, and it’s significantly easier than installing individual tools when we’re talking about shared tooling and local development. But hey, you do you!
  - benatkin 6y ago
    I'm about to uninstall Docker. I have a 128GB Macbook Air and it's taking up 17 gigs after some light use. I'll be using it from CI instead. I like it but it isn't a no-hassle option. It depends on the project whether it's easier. I prefer to avoid it if I can.
    - belval 6y ago
      Not to be that guy, but I feel the 128GB drive is more to blame than Docker at this point. 17GB just isn't that outlandish these days.
    - manquer 6y ago
      You can prune unused containers and images if didn’t know it already
oefrha 6y ago
Oops, missed it, thanks for the correction. Having to use docker certainly affirms "I get why it's probably not ideal as a local tool" to some extent, though...
- jbergknoff 6y ago
  On the contrary: Docker is currently the best way, bar none, of distributing tools like this one to developers. Kudos to the Super Linter developers for doing this right. I wrote an article a while ago arguing this point: https://jonathan.bergknoff.com/journal/run-more-stuff-in-docker/ https://jonathan.bergknoff.com/journal/run-more-stuff-in-doc...
  - zodiac 6y ago
    Regarding "cross-platform": Docker for Windows used to be really terrible IMO (relied on VirtualBox, did not translate WSL paths, etc). I never managed to get the networking between VirtualBox, WSL and applications (e.g. Chrome running in Windows) working properly. Thankfully Microsoft rewrote WSL 2 in a way that makes it work much better with Docker.
    - geewee 6y ago
      I've also had some bad experiences with Docker for windows but that was quite a few (2+ years ago) - since then it's mostly been smooth sailing for me, even without WSL
      - zodiac 6y ago
        My experience was that it used to be bad specifically because of the bad interactions with WSL (1)
avtar 6y ago
It's kind of odd that GitHub is asking people to pull an image from a Docker account that most people won't recognize (admiralawkbar/super-linter), as opposed to an official GitHub one.
- markrages 6y ago
  What was Admiral Ackbar's famous quote?
  - nemosaltat 6y ago
    It’s an exception?
  - whycombagator 6y ago
    “ask yourself if that answer doesn't make you look just a bit like a dewback's cloaca”
- anonova 6y ago
  Which is funny too because GitHub repos have Docker repository functionality: https://github.com/features/packages https://github.com/features/packages But since its release, you still can't do public pulls: https://github.community/t/docker-pull-from-public-github-package-registry-fail-with-no-basic-auth-credentials-error/16358/2 https://github.community/t/docker-pull-from-public-github-pa...
- myroon5 6y ago
  looks like it's changing now: https://github.com/github/super-linter/pull/137 https://github.com/github/super-linter/pull/137
- sdesol 6y ago
  GitHub's Super Linter has an unusual history. See below for example: https://imgur.com/KZ008vu https://imgur.com/KZ008vu https://imgur.com/yJSHIWS https://imgur.com/yJSHIWS admiralawkbar accounts for 80% of the commits in the repository and over 98% of the code churn. I'm guessing this was a side project of his (Lucas Gravley aka admiralawkbar) and the docker image was just something that was overlooked when it became an officially advertised GitHub repo.

Hi, there is a local run option with instructions here: https://github.com/github/super-linter/blob/master/docs/run-linter-locally.md https://github.com/github/super-linter/blob/master/docs/run-...

FalconSensei 6y ago

Have to install docker to run a linter... Nah, thanks.

GaryNumanVevo 6y ago
Docker is probably the least annoying solution, would you rather install linters for 40 different languages on your system?
- ori_b 6y ago
  I'd rather not run a linux VM for this, so yes. It should be possible to isolate it to /opt/github-linter/* on my BSD machines, or put into a nix package. (Also, I guess this is one more reason that docker is a big red flag for 'hastily hacked together unportable software that would be hell to ship.')
  - deleted 6y ago
    [deleted]
  - bastardoperator 6y ago
    Look at the Dockerfile, it's all there. All 143 lines and 2 bash scripts. Are you about to introduce a new BSD ports package?
  - philsnow 6y ago
    I'm 100% fine with running this and similar tools with docker to avoid polluting my machine with dependencies / un-uninstallable cruft and also to allow the people making such tools to concentrate on the tools and not supporting installation on 30 different platforms. Hell, docker even works on windows these days. but your comment made me think of this meme, which I can't not link to https://i.imgflip.com/24ac74.jpg https://i.imgflip.com/24ac74.jpg text for people who don't want to click: It works on my machine Then we'll ship your machine And that is how docker was born
- oefrha 6y ago
  Install linters as needed / pick up what's already installed could be a feasible option.
  - hobofan 6y ago
    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.)
deleted 6y ago
[deleted]
pensatoio 6y ago
Installing Docker is so easy, and it’s significantly easier than installing individual tools when we’re talking about shared tooling and local development. But hey, you do you!
- benatkin 6y ago
  I'm about to uninstall Docker. I have a 128GB Macbook Air and it's taking up 17 gigs after some light use. I'll be using it from CI instead. I like it but it isn't a no-hassle option. It depends on the project whether it's easier. I prefer to avoid it if I can.
  - belval 6y ago
    Not to be that guy, but I feel the 128GB drive is more to blame than Docker at this point. 17GB just isn't that outlandish these days.
  - manquer 6y ago
    You can prune unused containers and images if didn’t know it already

oefrha 6y ago

Oops, missed it, thanks for the correction. Having to use docker certainly affirms "I get why it's probably not ideal as a local tool" to some extent, though...

jbergknoff 6y ago
On the contrary: Docker is currently the best way, bar none, of distributing tools like this one to developers. Kudos to the Super Linter developers for doing this right. I wrote an article a while ago arguing this point: https://jonathan.bergknoff.com/journal/run-more-stuff-in-docker/ https://jonathan.bergknoff.com/journal/run-more-stuff-in-doc...
- zodiac 6y ago
  Regarding "cross-platform": Docker for Windows used to be really terrible IMO (relied on VirtualBox, did not translate WSL paths, etc). I never managed to get the networking between VirtualBox, WSL and applications (e.g. Chrome running in Windows) working properly. Thankfully Microsoft rewrote WSL 2 in a way that makes it work much better with Docker.
  - geewee 6y ago
    I've also had some bad experiences with Docker for windows but that was quite a few (2+ years ago) - since then it's mostly been smooth sailing for me, even without WSL
    - zodiac 6y ago
      My experience was that it used to be bad specifically because of the bad interactions with WSL (1)

avtar 6y ago

It's kind of odd that GitHub is asking people to pull an image from a Docker account that most people won't recognize (admiralawkbar/super-linter), as opposed to an official GitHub one.

markrages 6y ago
What was Admiral Ackbar's famous quote?
- nemosaltat 6y ago
  It’s an exception?
- whycombagator 6y ago
  “ask yourself if that answer doesn't make you look just a bit like a dewback's cloaca”
anonova 6y ago
Which is funny too because GitHub repos have Docker repository functionality: https://github.com/features/packages https://github.com/features/packages But since its release, you still can't do public pulls: https://github.community/t/docker-pull-from-public-github-package-registry-fail-with-no-basic-auth-credentials-error/16358/2 https://github.community/t/docker-pull-from-public-github-pa...
myroon5 6y ago
looks like it's changing now: https://github.com/github/super-linter/pull/137 https://github.com/github/super-linter/pull/137
sdesol 6y ago
GitHub's Super Linter has an unusual history. See below for example: https://imgur.com/KZ008vu https://imgur.com/KZ008vu https://imgur.com/yJSHIWS https://imgur.com/yJSHIWS admiralawkbar accounts for 80% of the commits in the repository and over 98% of the code churn. I'm guessing this was a side project of his (Lucas Gravley aka admiralawkbar) and the docker image was just something that was overlooked when it became an officially advertised GitHub repo.