Hacker News Reader

Comment by zkoppert | Hacker News Reader

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

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.

Which is funny too because GitHub repos have Docker repository functionality: 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-pa...

What was Admiral Ackbar's famous quote?

It’s an exception?

“ask yourself if that answer doesn't make you look just a bit like a dewback's cloaca”

looks like it's changing now: https://github.com/github/super-linter/pull/137

GitHub's Super Linter has an unusual history. See below for example:

https://imgur.com/KZ008vu

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.

Yup, thats exactly what happened.

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

Docker is probably the least annoying solution, would you rather install linters for 40 different languages on your system?

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.')

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?

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

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

Install linters as needed / pick up what's already installed could be a feasible option.

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

Outdated version could simply be counted as nonexistent, then a new version would be installed "as needed".

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.

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.)

Portage solved all that long ago. Parallel versions are called slots.

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!

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.

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.

You can prune unused containers and images if didn’t know it already

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...

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-doc...

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.

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

My experience was that it used to be bad specifically because of the bad interactions with WSL (1)

Reply on news.ycombinator.com