Why does installing the Pico vscode extension drag in an additional eight (8) superfluous extensions? I have only two extensions in my vscode install C/C++ and CMake Tools. That's all I really want, but the new "Getting Started" guide recommends installing the Raspberry Pi Pico vscode extension. While I normally don't use vscode and just use an editor and call cmake and make as needed, it is handy at times to open vscode to have it pull in all the #define values for easy cross-check rather than hunting through the pico-sdk to find them. That I do appreciate at times.
Not having used vscode with pico since the pico-sdk 2.x came out, when I opened vscode on an existing project, cmake failed with a toolchain error. After deleting the vscbld directory, that seemed to make cmake happy, but then it could not find #include files for the sdk. Editing the include path and adding /opt/pico-sdk/** made the include issue go away, but then errors remained because vscode couldn't find the definitions for true or false (even after including <stdbool.h>. So I just ended up defining them:
(why the pico-sdk doesn't have "true" and "false" sorted out if stdbool.h is included is for another day)
Fixed, code builds fine, but would the vscode extension have made that easier?
Page 1. of The Getting Started Introduction says [highlighted in a red box] "The main method covered in this book uses a VS Code extension to make your life easy." Let's install it. Download the .vsix from the pico-vscode github repository, validate then checksum and install. BAM - to my shock, it wasn't just "a" pico-vscode extension that was pulled in, but:
* Cortex-Debugger for GDB
* debug-tracker (generic debug tracker)
* Memory View
* MicroPico
* Peripheral (standalone peripheral SVD)
* Python (ms-python - WTF?)
* Python Debugger (ms-python - double WTF??)
* Raspberry Pi Pico (finally the extension I thought I was installing)
* RTOS Views
None of which are necessary to build and compile using cmake and gcc-arm-none-eabi, as the manual config in getting started provides. I don't use python, it is simply a type of snake to me and I don't want a M$ version of it installed. Additionally, the commits show this extension now relies on npm as a 3rd party package manager free to install needed parts of the various extensions behind the scene -- and opening your system up to supply-chain-attack.
There needs to be a clearer warning about what this extension is an what it will do on install, something to the effect of "The Pico VSCode extensions is a wrapper that will pull in an additional eight (8) extensions including .... the list ... and rely on NPM for aspects of package installation". Had this been clear, I wouldn't have touched this extensions with a 10-foot pole, but as it was I ended up installing it and then having the perform an exorcism to rid the vscode install of the demons that slipped in.
I get you want to make an all encompassing extensions that hides the manual config from newcomers, but in promoting this extensions, you need to at least make clear the ramifications of installing it, that it is not "a" singular extension and balance security considerations given its reliance on npm. (Just search "npm supply chain attack" or "npm malicious package" and the list goes on and on)
Is it really necessary to pull in all this in what is promoted as a single extension? Seems overkill. Why not at least separate out the python tools? This is after all for building using a C-sdk?
Not having used vscode with pico since the pico-sdk 2.x came out, when I opened vscode on an existing project, cmake failed with a toolchain error. After deleting the vscbld directory, that seemed to make cmake happy, but then it could not find #include files for the sdk. Editing the include path and adding /opt/pico-sdk/** made the include issue go away, but then errors remained because vscode couldn't find the definitions for true or false (even after including <stdbool.h>. So I just ended up defining them:
Code:
#ifndef trueenum { false, true = !false };#endifFixed, code builds fine, but would the vscode extension have made that easier?
Page 1. of The Getting Started Introduction says [highlighted in a red box] "The main method covered in this book uses a VS Code extension to make your life easy." Let's install it. Download the .vsix from the pico-vscode github repository, validate then checksum and install. BAM - to my shock, it wasn't just "a" pico-vscode extension that was pulled in, but:
* Cortex-Debugger for GDB
* debug-tracker (generic debug tracker)
* Memory View
* MicroPico
* Peripheral (standalone peripheral SVD)
* Python (ms-python - WTF?)
* Python Debugger (ms-python - double WTF??)
* Raspberry Pi Pico (finally the extension I thought I was installing)
* RTOS Views
None of which are necessary to build and compile using cmake and gcc-arm-none-eabi, as the manual config in getting started provides. I don't use python, it is simply a type of snake to me and I don't want a M$ version of it installed. Additionally, the commits show this extension now relies on npm as a 3rd party package manager free to install needed parts of the various extensions behind the scene -- and opening your system up to supply-chain-attack.
There needs to be a clearer warning about what this extension is an what it will do on install, something to the effect of "The Pico VSCode extensions is a wrapper that will pull in an additional eight (8) extensions including .... the list ... and rely on NPM for aspects of package installation". Had this been clear, I wouldn't have touched this extensions with a 10-foot pole, but as it was I ended up installing it and then having the perform an exorcism to rid the vscode install of the demons that slipped in.
I get you want to make an all encompassing extensions that hides the manual config from newcomers, but in promoting this extensions, you need to at least make clear the ramifications of installing it, that it is not "a" singular extension and balance security considerations given its reliance on npm. (Just search "npm supply chain attack" or "npm malicious package" and the list goes on and on)
Is it really necessary to pull in all this in what is promoted as a single extension? Seems overkill. Why not at least separate out the python tools? This is after all for building using a C-sdk?
Statistics: Posted by drankinatty — Tue Jul 22, 2025 1:35 am — Replies 1 — Views 69