Atom-ide-ui: [FR][Difficult] Support Docker integration

[alexandernst]

A very common workflow nowadays is to have a docker container(s) that runs the code and just have a volume bind between the host and the guest with the code.

Develops usually prefer working inside containers because that way they don't have to mess with the host system/libraries.

That leads me to the actual problem: most developers will install, say, python3 + django + pylint + jedi + whatever inside their container and rely on those to lint and run the code.

The way Atom-ide-ui (and all related linters) currently works (using local binaries from the host OS) makes it impossible to use atom-ide-ui without installing everything on the host itself.

It would be very nice if you could, somehow, integrate with Docker (and other containers and VMs).
One possible solution would be to use SSH and some kind of RPC with a server inside the container that would then run the required commands, parse the output of the linters, etc... and return the result (via that RPC mechanism) to the host.

[Arcanemagus]

Probably the best way to get this working would be to use the LSP that this ecosystem is already built around: Although it seems this is rarely used it _can_ run over a TCP connection so you could have a language server running in the container that _just_ did diagnostics, and have a atom-languageclient based package for Atom that talked to it.

I'm not sure that the atom-ide-ui repo is the best place to work on that though as it only really has to do with the _display_ of diagnostics data, not the actual running of providers on it.

[semmypurewal]

We currently support remote development through the monolithic Nuclide package. This should work seamlessly with docker containers.

It's on our roadmap to break out the remote development piece of Nuclide into its own package so it can be used alongside Atom-IDE. We're hoping to have that ready for release by the beginning/middle of next half.

[alexandernst]

Nice!! Is there an issue I can track?

[semmypurewal]

Sorry, we don't have an external-facing issue for this at the moment! But feel free to keep an eye on the Nuclide package for more info.

[alexandernst]

Maybe just keep this issue open and close it when it’s done and working?

I feel like this is quite an important thing and closing this issues rests importancy to it.

[bhack]

@alexandernst Check features of https://github.com/Azure/vscode-kubernetes-tools

[bhack]

Also, if you want, subscribe to https://github.com/atom/atom/issues/14860 but there was not so much activities.

[bhack]

I agree with @alexandernst that we need an issue to track this topic.
Docker and kubernetes will be more and more dominant dev loop use case and Kubernetes will be integrated in the Docker distribution soon (in Minikube flavour) cause it is already in the edge channel

[bhack]

Another solution but only with vscode plugin https://github.com/solo-io/kubesquash/

[alexandernst]

@bhack but does that require running k8s?

[bhack]

Yes but it is strictly related to Docker and a quite common setup for dev that works with containers. Seems that many K8s/Docker related companies are pushing over vscode plugins instead of Atom. Atom ecosystem is totally ingoring this new trends.

[alexandernst]

Why would I (anyone?) run k8s in local to develop?

[bhack]

Generally in local devs use Minikube before to deploy on K8S cluster on AWS/GCE/Bare metal etc. Microservice development it is becoming quite relevant.