skaffold debug may need to apply IDE-specific language runtime bindings

[briandealwis]

Different IDEs may require different combinations of language runtime support packages. For example, IDEA/PyCharm does not support the Debug Adapter Protocol, so ptvsd for Python will not work out of the box. Instead it needs to use a separate package, pydevd-pycharm to enable remote debugging. And unfortunately it seems to require running some code on startup to enable.

We can maybe try to support this by a command-line specified "flavour" or "kind".

[corneliusweig]

Could that be handled together with #2203? E.g.

artifacts:
- image: foobar
  runtimeType: python
  # or
  runtimeType: python-idea

[briandealwis]

IDEs shouldn't need to modify the skaffold.yaml.

[tstromberg]

Marking as stale, since it's been a while and does not appear to be on the teams priority radar. Feel free to reopen if you disagree.

[briandealwis]

Re-opening but marking as p3 as we know it's an issue but other issues were higher priority.

[briandealwis]

With Delve's DAP finishing up, we'll need to support this soon. Rather than trying to maintain IDE-compatibility tables, I think it's best if the IDEs specify a list of supported protocols. For example, CC-VSC could run:

skaffold debug --protocols dap

whereas CC-IJ would run:

skaffold debug --protocols dlv,jdwp,pydevd,nodejs

Pros:

• not IDE specific: spares Skaffold from having to maintain compatibility tables
• if an IDE adds new support for a protocol, it can just add it to their list

Cons:

• could become unwieldy?
• our metrics would benefit from being able to report a specific client type

cc: @quoctruong @etanshaul @petlin

[etanshaul]

how timely! I just wrote up: https://docs.google.com/document/d/1Dj52OayWFFa_3dBSzvt3-xWFIGLvm0oyGswRW4oV0KI, so I think we can converge on this.

[etanshaul]

I like how you differentiate between DAP and everything else. Though the slight oddity is that for some runtimes (like Java), afaik the set of transforms for say dap vs jdwp will be identical.

Also, I wonder if there is ever a case where we'd want to support a mix of DAP and non-DAP protocols in a single invocation (e.g. backwards compatibility with older versions of VSC, pre-Go-DAP)

could become unwieldy?

How do you figure this? Do you mean because JB has to manually specificy all of the individual protocols?

[nkubala]

could become unwieldy?

seems like a small price to pay for the flexibility this grants, otherwise we're going to have to coordinate on both sides every time a new debug protocol is added.

my only question is, what happens when two separate protocols for the same language are provided? we can't use both at the same time, so would we select arbitrarily or fail out?

[etanshaul]

my only question is, what happens when two separate protocols for the same language are provided? we can't use both at the same time, so would we select arbitrarily or fail out?

I think we should default to DAP unless specified. I updated the referenced design above with this proposal.

[briandealwis]

This was fixed by #5759 — thanks @matthewmichihara!