Utilize VScode extension profiles with the plugin to make it easier to use and switch between sets of extensions (different toolchains)

[eriklundh]

VSCode is an impressive environment, that used to have a problem running different sets of extensions, requiring users to manually disable and enable several conflicting extensions from different vendors, e g Raspberry Pico vs ESP32 toolchains.
The VSCode devs addressed this problem some time ago by introducing 'extension profiles'.
https://code.visualstudio.com/docs/editor/profiles
Profiles was a command line switch at first, but now also has a UI in VSCode.
Different VSCode instances can run different extension profiles, making the platform less of a 'everything looks like a nail when all you have is a hammer'. I e you can run Pico development in one VSCode window, and development that requires a conflicting set of extensions in another VSCode window.
This seems to be intended to make VSCode-based solutions more attractive to ambitious devs that don't want to get stuck as sad one-trick ponies.
However, we have not yet seen any MCU toolchain installer that automatically installs in a separate VSCode profile instead of the default extension profile space. (We did suggest using VSCode extension profiles to some esp-idf devs at Embedded World 2024)
Bonus level
I have not verified this, but it might be possible to have kind of a "benign" proxy VSCode extension without conflict-causing dependencies that can live in the default profile (default extension space) that, when activated, automatically switch to the pico-vscode profile, with the right set of extensions. Might improve usability for the majority of users currently unaware of VSCode extension profiles

[eriklundh]

In the README I noticed the known limitations about custom tool paths.
You might find it useful to conditionally include a user custom settings file at the end of the generated cmake include. Including an custom overrides file at the appropriate place in the settings bootstrap sequence is a common pattern in e g Linux.
I e:
if(EXISTS path-to-file-or-directory)
include(pico_custom_settings.cmake)

According to stackoverflow there might be some caveats with IF(exists filename) in CMAKE, but they seem manageable by generating the right CMake syntax.

[will-v-pi]

I don't think we'll implement this by default, as it would add an extra step of selecting the right profile to the Getting Started guide. But you're welcome to submit a PR adding some notes about using profiles to the readme if you want - they do look like a very useful feature for more advanced developers.

[eriklundh]

I also suggested ways to make the extra step of selecting a profile as transparent as possible.
My suggestions aim at bringing Raspberry Ltd an edge in the professional embedded developer space, not just cater to one trick pony hobbyists. Try Install a few different tool chains in Vscode from competing silicon vendors, and you will be in a world of hurt. Cleaning up and and reinstalling as needed is quite cumbersome, since all the vendors extensions have dependencies that often conflict. In any case but a junior engineer with a clean slate machine, these conflicts might keep professional customers from adopting rp2xxx just because some other silicon vendors was there first, old projects needs to be maintained, or the project require development of firmware for several different vendors MCUs. For some bakgrund on why my industrial perspective might be relevant, you might ask some of your coworkers about my industrial background. In particular the gentleman that occasionally are confused with Jason Statham know me since 2012.

[will-v-pi]

I've added a note on VS Code profiles to the readme, including a sample profile, with provides a method to install the extension into a Pico profile rather than installing into the Default profile. I hope that this meets your needs. The VS Code API currently doesn't give extensions access to Profile settings, so we wouldn't be able to default to installing into a profile anyway without modifying system VS Code files.

[eriklundh]

I suggest that you look into this vscode issue microsoft/vscode#188105
It is a much discussed topic among developers.
If Raspberry AND e g Espressif joined forces on this issue, the needle might move.
I discussed the use of vscode profiles with Ivan Grothotkov, head of Espressif sw tools (based in Czech republic) at the Embedded World 2024 faire.
pico-vscode was not on my radar at that time, although I passed by the Raspberry booth and bumped into your founder/ceo in an aisle at the faire.

[eriklundh]

I myself use several toolchains, not daily, but I do switch between dev envrionments for RP2xxx, Espressif,Silabs and STM32.
I do know of super-productive multidisciplinary hardware/software designers that finish as much as 5 professional design projects that goes to production per week. Non-technical sales people might translate that to 5 safe "design wins" per week if you make your particular brand platform attractive enough to stay within eg the Raspberry rp2xxx eco-system. But the reality is that these super-productive designers need to optimize their designs. They either dislike lock-in or go with just one MCU brand, more often than not it will be STM32.
When you cater to the design professionals, avoid lock-ins.
These professionals might be die-hards on which CAD package they use, but they would like to have much more flexibility in which MCU flavor or brand they choose.