-
Notifications
You must be signed in to change notification settings - Fork 134
Description
Positron ships with a set of "bootstrapped" extensions, which are bundled with Positron and auto-installed when the user starts Positron, if they are not already installed.
Lines 120 to 134 in 79aa845
| "bootstrapExtensions": [ | |
| { | |
| "name": "charliermarsh.ruff", | |
| "version": "2025.32.0", | |
| "repo": "https://github.com/astral-sh/ruff-vscode", | |
| "metadata": { | |
| "publisherId": { | |
| "publisherName": "charliermarsh", | |
| "displayName": "Ruff", | |
| "flags": "verified" | |
| }, | |
| "publisherDisplayName": "charliermarsh", | |
| "multiPlatformServiceUrl": "https://open-vsx.org/api" | |
| } | |
| }, |
While we can use this list to add bootstrapped extensions, we cannot use it to remove previously installed bootstrapped extensions. This means that if we replace a bootstrapped extension with a different one, users will wind up with both. This has, in fact, already happened, with pyright and pyrefly.
Proposal
- When a bootstrapped extension is installed by us, we write some metadata indicating that we are managing the installation.
- This metadata persists if the extension is updated from the marketplace (as this is one of the reasons we use bootstrapped extensions)
- When we detect an extension that has an installation managed by our bootstrapper but is no longer in the list of bootstrapped extensions, we remove it automatically.
Another way to approach this would be to have a (computed) version applied to the set of bootstrapped extensions, and to generate the set of actions to take based on the difference between the users' current version and the version of Positron that is starting. This would allow us to more or less respect all user modifications since we'd only be performing the changes between versions, not resetting everything every time (related to #8308).