Dependent commands within launch.json

[scabana]

Enable a scenario like this one:

{
    "name": ".NET Core Docker Attach",
    "type": "coreclr",
    "request": "attach",
    "processId": "${command:2:pickRemoteProcess}",
    "pipeTransport": {
      "pipeProgram": "docker",
      "pipeArgs": ["exec", "-i", "${command:1:pickDockerContainer}"],
      "debuggerPath": "/vsdbg/vsdbg",
      "pipeCwd": "${workspaceRoot}",
      "quoteArgs": false
    }
}

The pickRemoteProcess command uses the launch task config, but in this case pickDockerContainer requires to be fulfilled before pickRemoteProcess is invoked. The variable substitution syntax should allow for an order of execution and should fulfill (or update) configuration each time a substitution is handled.

Would enable microsoft/vscode-docker#1235 to work.

[weinand]

You can determine the evaluation order by rearranging the lines in the launch config. Is it really necessary to introduce a special syntax for this?

/cc @alexr00

[scabana]

If you consider having two variables total then no. If you consider having more than two, not allowing an order parameter is not enough in a case like this one:

{
    "name": ".NET Core Docker Attach",
    "type": "coreclr",
    "request": "attach",
    "processId": "${command:2:pickRemoteProcess}",
    "pipeTransport": {
      "pipeProgram": "docker",
      "pipeArgs": ["exec", "-i", "${command:1:pickDockerContainer}"],
      "debuggerPath": "/vsdbg/vsdbg",
      "pipeCwd": "${command:3:pickSomeFolder}",
      "quoteArgs": false
    }
}

Where command order would require to be:

1. pickDockerContainer
2. pickRemoteProcess
3. pickSomeFolder

But then there's no way to order the json to allow for it.

I do agree it's adding complexity in both the vscode code base and in its usage. In my specific case, I could live without the order parameter. Although, forcing the order of the json to apply the variables is counter intuitive since json is usually not ordered. Also, it would make this example be ordered differently than all examples of remote debugging with omnisharp and devs would need to "find out somehow" that order is important instead of getting an hint with an explicit order in the variable syntax. With that said, I'd be willing to remove the order syntax to get the rest of the code in.

[scabana]

Hi @weinand ,

I removed the ordering part of it since it introduces complexity that's not required. An alternative would be to handle it in the variables instead, add an order property and get its order out of the variables' json instead, would be much simpler I guess.

Should I keep the PR opened? Is there value for vscode?

Thanks a lot!

[weinand]

From #89758 I've copied my analysis of the problem:

Today variable substitution is a two phase process:

• Phase 1: the value of all variables is determined.
• Phase 2: all variables are substituted with their new values.

If a variable is command-based (e.g. relying on some code running in an extension), the extension code has only access to the unresolved launch configuration, that means it does not see other already resolved variables. The reason for this behavior is isolation and independence from evaluation order.

A consequence of this is that a launch configuration can not be considered a "sequential program", that is executed from top to bottom.

I firmly believe, that this approach is a "good design" even if it has limitations.

If I understand the PR #92697 from @davidruhmann correctly, then he wants to change variable substitution to this:

• determine the value of the first/next variable
• substitute all occurrences of that variable with the new value
• continue with the next variable

If a variable is command-based and has access to the (partially) resolved launch config, then its value becomes order dependent.

This is a problem, because we cannot preserve the order of properties in a JSON. The order might deviate from the order a user sees in the JSON's source (e.g. the launch configuration).

[weinand]

As explained above variable substitution is a two phase process for good reasons.
It is in place for some time and we are no longer in a position to change variable substitution in order to accommodate the use of launch configurations as sequential programs.

A launch.json is a configuration mechanism and variable substitution is just a macro mechanism.
We are aware of the limitations imposed by this, but we have no plans to solve them on the VS Code side.