`probe-rs` prompts user for binary installation within non-Rust projects

[opeik]

Hi there,

I don't like installing tools globally (because it's far too easy to lose track of project dependencies) and prefer to use Nix flakes to keep everything self-contained. A problem I run into daily is probe-rs asking to install the binary despite the project not containing any Rust source files. I think it only makes sense to prompt the user if they're currently within a Rust source file/project.

[Jack-NimbleTron]

Your concerns are valid, and I would gladly consider any PR's against this.

Before we get to that point, perhaps it is worth clarifying the desired behaviour and facts ...

1. The probe-rs executable (the DAP server)) needs to be present to allow probe-rs VSCdode extension (the DAP client) to operate. It has nothing to do with whether or not the project contains Rust source code.
2. The probe-rs VSCode extension should only activate if there is a launch.json configuration that references it. Does your project have a config that references probe-rs-debug?
3. The auto install should only trigger if there is no probe-rs binary in the path, so perhaps a temporary workaround is for your Nix flakes to point to a known probe-rs binary?
4. It should be relatively easy (the project already contains similar code) to PR a change that looks at a probe-rs specific setting in VSCode, and bypasses the binary install if the user has chose to disable this.

Thoughts?

[opeik]

@Jack-NimbleTron Hi there! Thanks for getting back to me.

1. The probe-rs executable (the DAP server)) needs to be present to allow probe-rs VSCdode extension (the DAP client) to operate. It has nothing to do with whether or not the project contains Rust source code.

I haven't done any VSCode extension development, so please forgive me if I'm totally off the mark, but probe-rs is for debugging Rust projects, right? Why is the extension even starting if I open a Go file? In contrast, rust-lang.rust-analyzer also requires a binary to function but the extension doesn't start if I open a non-Rust source file, meaning it won't prompt the user, so the problem solves itself.

Well, either that or the extension starts regardless but it won't prompt the user to install the binary unless they've opened a Rust source file. Either way, the result is the same.

3. The auto install should only trigger if there is no probe-rs binary in the path, so perhaps a temporary workaround is for your Nix flakes to point to a known probe-rs binary?

I've considered this, but now I'm just globally installing tools again, and that's what I'm trying to avoid.

4. It should be relatively easy (the project already contains similar code) to PR a change that looks at a probe-rs specific setting in VSCode, and bypasses the binary install if the user has chose to disable this.

I'm happy to cook up a PR, but I feel the current behaviour is not in line with other extensions that require additional binaries (see my point above). Adding an option to enable the expected behaviour feels less than ideal.

[Jack-NimbleTron]

In this context, probe-rs-debug is a VSCode extension, that implements the MS DAP protocol, and connects to a probe-rs DAP server, to allow you to connect to a USB connected probe for flashing and debugging embedded binaries. It was developed using TypeScript for the extension, and Rust for the server, but it enables embedded debugging irrespective of what language the embedded binary was developed in. Does that differentiation make sense?

The extension should ONLY start if you have a launch.json profile that refers to it. This is true for other debug extensions also as far as I understand. My question #2 above ... do you have such a config?

[opeik]

It was developed using TypeScript for the extension, and Rust for the server, but it enables embedded debugging irrespective of what language the embedded binary was developed in. Does that differentiation make sense?

Ahh, that makes sense, I thought it was for embedded Rust projects only. Adding an extension setting is probably the best way to go about this, right?

The extension should ONLY start if you have a launch.json profile that refers to it. This is true for other debug extensions also as far as I understand. My question https://github.com/probe-rs/vscode/pull/2 above ... do you have such a config?

I don't think so? This was the launch.json for the project that triggered the prompt in my first post:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "{redacted}",
      "type": "go",
      "request": "launch",
      "mode": "auto",
      "program": "${workspaceFolder}/main.go",
      "env": {
        "{redacted}": "false",
      }
    }
  ]
}

[Jack-NimbleTron]

Yes, an extension setting would be a good workaround, ... but, if you only have "type": "go" and not "type": "probe-rs-debug", then the correct fix is to make sure we move the check forprobe-rs binary to the correct event in the extension code. I have not investigated the details, but I would imagine there is a way to differentiate between the extension being present and installed, versus the extension being activated by an active launch configuration. If that check is done in the latter, and not the former, then there would be no need for an extension setting.

[Yatekii]

Can't you click on the cogwheel and say "don't show again"?

[Jack-NimbleTron]

Yes, it says "Turn off Info and Warning notifications from extension name" ... that would do I don't see any docs on whether this is workspace dependent or global config, so it might interfere with future use of the extension.

But that does remind me ... VSCode now supports Profiles, where individual extensions can be disabled/enabled, so that would provide a clean solution.

[opeik]

Can't you click on the cogwheel and say "don't show again"?

As far as I can tell, that option will silence all notifications from the extension, which isn't ideal.

[Jack-NimbleTron]

@opeik I agree. I also know from experience that it is not easy to go back later and turn it back on ... can't find it LOL

What about the idea of creating a VSCode profile assigned to this project, that excludes the probe-rs-debug extension?