No clue how large the scope of this work is, but in the original announcement for atom-ide, it was mentioned that adding a debugger (presumably reusing most of the one from nuclide) would be part of the future roadmap. Wanted to start a discussion around this to get a sense of priority and timeline. This would be _super_ useful and for me seems to be the biggest remaining gap in atom-ide living up to its name.
If you build from the latest master, you'll see that commands and UI for the debugger have already been added.... ;)
@mostafaeweda and @velocityboy are currently finalizing the details of how the API will work for implementors of the debugger. So stay tuned! Perhaps they can give an update of the expected timeline.
That's awesome to hear - thanks @hansonw!
We're finalizing the initial debugger platform integration API + we'll provide default implementations for Node, Python & other debuggers.
Also, that'd bridge the gap in https://github.com/atom/atom/issues/9841
What about remote (or in container) debug support? https://github.com/atom/atom/issues/14860
I.e. just as an example (still not automated) of python/vscode https://github.com/DonJayamanne/vscode-python-samples?files=1
In Nuclide’s environment, remotability is a first class citizen (hence, all debuggers work locally and remotely - regardless if any debugger-specific support) — so, if you need remote debugging support, I’d encourage you to install the bugger Nuclide package instead of just Atom IDE as that remotability isn’t yet in the Atom IDE environment (but there’s a long term effort to standardize it and bring it over)
atom-ide-debugger uses the VSCode debugger protocol so it's easy to adapt
most of the VScode debugger plugins - in fact we'll probably publish a
Python debugger that uses the one in the repo you linked. It looks like the
"remote debugging" support is just attaching to a port exposed by the
Docker container, so that should be easy to set up.
On Sun, Apr 8, 2018, 4:25 AM bhack notifications@github.com wrote:
I.e. just as an example (still not automated) of python/vscode
https://github.com/DonJayamanne/vscode-python-samples?files=1—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook-atom/atom-ide-ui/issues/196#issuecomment-379542651,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjPYgMKCq3y1Mw6MqA0w7aEPs_Jftmyks5tmfOlgaJpZM4TECbD
.
@hansonw Yes but recently the kubernetes dev tool ecosystem is quite in fermentation cause there is a high demand of managing the dev/build/deploy/run/debug cycle. So generally the image and containers are build automatically (and also the port and attaching mechanism need to be automated). This is not strictly constrained in the debugger perimeter but also for the language server and interpreter/execution. See https://github.com/GoogleCloudPlatform/skaffold/issues/348
Something interesting is happening already in vscode https://github.com/Azure/vscode-kubernetes-tools/
In specific for the debugger: https://github.com/Azure/vscode-kubernetes-tools/pull/160
I just finished v1 of atom-ide-debugger as part of https://ide.atom.io/ with some debuggers initially supported:
Awesome! I'm still missing some documentation (in the README?) how to provide a debugger and what needs to be done.
Reading existing debuggers is ok, but some additional documentation would be handy :)
I was going to do that tomorrow :+1:
Most helpful comment
We're finalizing the initial debugger platform integration API + we'll provide default implementations for Node, Python & other debuggers.
Also, that'd bridge the gap in https://github.com/atom/atom/issues/9841