'openocd' is not recognized as an internal or external command - is it Windows 11 issue?

[tdjastrzebski]

Yesterday I have tried to install OpenOCD on Windows 11. I have installed OpenOCD on Windows 10 many times before with no issues.

npm install --global xpm@latest
xpm install --global @xpack-dev-tools/openocd

The error message I get trying to run openocd:
'openocd' is not recognized as an internal or external command
Apparently, some path is not set right. Where should I look? I realized I did not know how xpm actually worked. On Windows packs are stored under %APPDATA%/xPacks in separate folders, so adding this path to PATH variable will not fix it.
Please advise.

[ilg-ul]

By design, xPacks allow different projects to be locked to different versions of a package, thus the need to install versions in separate folders, and not in system locations.

The easiest way to use xPacks is to install them non-globally, as instructed in the release page. This will not waste any space, since only links and forwarders are used.

[tdjastrzebski]

@ilg-ul Thanks, it makes sense, although I am still not sure what the solution should be. Should I install openocd without using --global switch? But this brings error: installing standalone binary xPack not supported, use --global

[ilg-ul]

Please read the release page, as instructed:

https://xpack.github.io/blog/2022/03/25/openocd-v0-11-0-4-released/

[ilg-ul]

It is possible to further automate things, you can add an xPack action (which is basically a named script) and invoke it with xpm run <name>, which automatically updates the PATH to include xpacks/.bin.

Here are some examples:

• https://marketplace.visualstudio.com/items?itemName=ilg-vscode.xpack

[tdjastrzebski]

Thank you, I got it. Probably, previously I had openocd installed in some other location on the PATH and that is why it worked.
I installed openocd locally using:

cd my-project
xpm init
xpm install @xpack-dev-tools/openocd@latest

Then I moved the content of my-project\xpacks\.bin to %AppData%\Roaming\npm and I should be a happy camper.
I actually do not want my projects to even be able to use different tool versions. I'd rather fix what needs to be fixed when the time comes and use the latest-greatest again than fall into tool versionitis.

[ilg-ul]

Then I moved the content of my-project\xpacks.bin to %AppData%\Roaming\npm and I should be a happy camper.

Ah, sure, but this is definitely not how things were supposed to work, it is too tedious, plus that I cannot guarantee it to be trouble free.

On my xpm TODO list there is a feature request to add some global links for globally installed packages; in a future release it'll probably be implemented.

[tdjastrzebski]

This would be a great enhancement!
I understand that typically tool versioning needs to be carefully managed and xpm greatly supports this process but some can afford an altogether different approach while still could benefit from xpm using it the way npm or pip is used. Probably all what is required is registered path to %AppData%/xPacks folder and bash/PS/cmd scripts underneath.
How this reconciles with the original concept? That's probably a different story.