Scaffold a Python Attach Configuration as part of compose

[haniamr]

If the user opted in for compose, we should scaffold a Python Attach Configuration:

{
      "name": "Python: Remote Attach",
      "type": "python",
      "request": "attach",
      "port": 5678,
      "host": "localhost",
      "pathMappings": [
        {
          "localRoot": "${workspaceFolder}",
          "remoteRoot": "/app"
        }
      ]
}

[bwateratmsft]

@haniamr Is it possible to use compose but do a Python launch config--sorta like we do with .NET Core in Visual Studio?

[ucheNkadiCode]

@haniamr Is it possible to use compose but do a Python launch config--sorta like we do with .NET Core in Visual Studio?

If the person selects compose, could we make it such that instead scaffolding a "Python: Remote Attach", we scaffold a "Docker: Compose Attach" configuration that does basically the same thing but aims to run a debug.yml file?

[bwateratmsft]

I'd prefer to do a Python remote attach so that we don't box ourselves out of adding "real" compose debugging someday. The .NET Core attach config is already going to cause problems; it will most likely need to be removed from launch configs upon upgrading the project to support "real" compose debugging.

[haniamr]

@haniamr Is it possible to use compose but do a Python launch config--sorta like we do with .NET Core in Visual Studio?

I suppose that is possible, we'd have to modify the entry point we generate in the debug yaml to be something like "pip install debugpy && python", then use our custom launcher. The problem is that the property we use to override the launcher isn't documented by the Python extension, so it'll have some warnings/squiggly lines...

[ucheNkadiCode]

Yea I agree with you Brandon, due to the low number of debugging usage as it is, it likely wouldn't be impactful to spend our time enabling the "real" compose debugging scenario. However, I'm more suggesting to make it streamlined that the user has the ability to run the Attach scenario for compose with an F5 since we'll be scaffolding tasks, a debug.yml file, and an Attach configuration anyway. It would be a launch config that ties it all together

[bwateratmsft]

What I'm saying is that with scaffolding scenarios--since it's not really possible to change things after they are scaffolded--it's better if we do not do half-measures. Anyone who uses the half-measure is effectively stuck there forever.

[ucheNkadiCode]

So do you consider scaffolding Two launch configurations contingent on if the user selects yes to Compose a "half measure"? I imagine this being a comprehensive way to run if this Docker Compose Launch configuration basically composes up with the debug.yml (which installs debugpy by default), then is able to run the Python attach afterwards for debugging a selected container.

But this seems like Net New technology since I don't believe we have a "Wait for compose up to finish then attach" feature. So is this possible/impossible? Would this be too large of an investment for an improved compose debugging user experience? Totally open to your response

[bwateratmsft]

Attach configurations are only marginally useful compared to launch. What I don't want to do is spend time implementing an attach configuration resolved through the docker launch config, which we will now need to support ~forever, when instead we can scaffold a Python attach config that does the same thing (but is more verbose).

Yellow squiggles for undocumented properties in the launch configs aren't a particularly big deal, but we should ask the Python team to document them (in package.json) so it isn't an issue.

[ucheNkadiCode]

So should this issue be closed? Or is the work to be done to relay specific attributes to the Python team that we want them to document so they no longer produce Yellow squiggles?

@haniamr or @bwateratmsft , What are the attributes that need to be updated? Is that a quick email to the Python team?

[bwateratmsft]

I don't think we need to close the issue; I just think that our scaffolding for this should be a launch config with "type": "python", not one with "type": "docker".

[haniamr]

Attach configurations are only marginally useful compared to launch. What I don't want to do is spend time implementing an attach configuration resolved through the docker launch config, which we will now need to support ~forever, when instead we can scaffold a Python attach config that does the same thing (but is more verbose).

Yellow squiggles for undocumented properties in the launch configs aren't a particularly big deal, but we should ask the Python team to document them (in package.json) so it isn't an issue.

The yellow squiggles part will only be the case if we scaffold a Python launch configuration. If we decided to go with the normal Python Attach, then it should be fine without any squiggles.

We can always go with the attach for now, and change it later to launch when the Python extension team documents the new property.