Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support pinning extension version when installed from CLI #63903

Closed
sandy081 opened this issue Nov 28, 2018 · 21 comments · Fixed by #171247
Closed

Support pinning extension version when installed from CLI #63903

sandy081 opened this issue Nov 28, 2018 · 21 comments · Fixed by #171247
Assignees
Labels
extensions Issues concerning extensions feature-request Request for new features or functionality insiders-released Patch has been released in VS Code Insiders on-testplan
Milestone

Comments

@sandy081
Copy link
Member

Follow up item from #12764

Do not trigger auto updates when a specific version of extension is installed from CLI

@sandy081
Copy link
Member Author

sandy081 commented Mar 6, 2019

This depends on availability of Storage Service in the cli process. @bpasero Let me know if it is feasible otherwise I would close it as a technical limitation.

@sandy081 sandy081 modified the milestones: March 2019, Backlog Mar 6, 2019
@bpasero
Copy link
Member

bpasero commented Mar 6, 2019

If main is already running there is a small chance that you see an error when reading items because the DB is in use. I assume you are not writing values right?

@sandy081
Copy link
Member Author

sandy081 commented Mar 6, 2019

I have to write into storage to ignore auto updating an extension.

@bpasero
Copy link
Member

bpasero commented Mar 7, 2019

@sandy081 got it. In that case I would suggest to:

  • write into storage if CLI is the only process running
  • otherwise ask the main process to do that

Reading should be fine from the CLI in either cases.

@sandy081
Copy link
Member Author

sandy081 commented Mar 7, 2019

Cool, Is there a way to check if cli is the only process running?

@bpasero
Copy link
Member

bpasero commented Mar 7, 2019

@sandy081 maybe @joaomoreno knows

@joaomoreno
Copy link
Member

When main starts up, the first thing it tries to create a socket for IPC. If it fails with EADDRINUSE, it means another main is already running, so it tries to connect to the existing main instance. This is how we make sure only one main runs, yet follow up mains send argv to that initial instance and we're able to open files on that initial instance.

CLI needs to join in on this dance. It should try to connect to that IPC channel. If successful, it should just tell that main what it should do. Else, it should do it itself, as quickly as possible.

@sandy081 sandy081 modified the milestones: Backlog, March 2019 Mar 8, 2019
@sandy081 sandy081 modified the milestones: March 2019, On Deck Mar 25, 2019
@Falconne
Copy link

It seems that now, even if you install a specific older version via the GUI with "Install Another Version ...", VS Code will immediately auto update the extension to the latest version after a reload. Based on #12764 I assume this is a regression.

I noticed this when I tried to rollback the PowerShell extension as the latest version broke auto-formatting.

I don't know if I should open a new issue for that as this functionality seems to be universally broken now and not just CLI specific, but figured I'd comment here first.

@sandy081
Copy link
Member Author

@Falconne Yeah it was broken and fixed it in insiders.

@lovette
Copy link

lovette commented Mar 31, 2022

I'm surprised this issue doesn't have more activity. I'm running into a related issue today.

The latest ms-python extension no longer supports Python 2.7 so I need to ensure an older version of the extension is installed when I attach to some remote containers. As it stands, Code installs the latest Python extension (as well as the Jupyter extension, which I never use and cannot find a way to disable.) I then have to downgrade ms-python, uninstall ms-toolsai.jupyter and relaunch the connection. (At this point a node process more often than not goes ballistic and eats up all the CPU until the container itself is restarted.) I wish I could simply include ms-python.python-2022.2.1924087327 in the extensions list of the named container settings .json.

(Note that I'm using Remote-SSH to connect to a remote host then using Remote-Containers to attach to containers on that host. It is lost on me if/how a devcontainer.json comes into play here.)

@twodrops
Copy link

twodrops commented Apr 26, 2022

This issue is really imporant for us as well. We have a safety critical development environment where we baseline our tools and roll it our as Docker Image + devcontainer.json. Because of this bug, the extensions are automatically updated on the user side. This comment by @lawrencegripper describes our problem clearly.

	"settings": {
		"extensions.autoUpdate": "false",
		"extensions.autoCheckUpdates": false,

	},
	"extensions": [
		"my-extension@0.0.1"
	]

The problem becomes more severe when the extensions have two parts, an extension and a python based backend for it (like a language server). The frontend part of the extension easily runs out of sync because of the auto-update feature. We do not want to let users install the backend manually with a notification, as it can, for example, cause a lot of pip issues/conflicts.

@ras-relativity
Copy link

Dealing with this with omnisharp/C# extension.

The team needs v1.23.16, but it installs the latest (currently v1.24.4) on container startup. To fix:

  1. Go to the C# extension in extension tab
  2. Click the dropdown next to Uninstall Button -> Install another version -> v1.23.16
  3. Click the Reload Required button

We use a devcontainer.json to install the extension, would like to put this, but it has no effect:
"extensions": [ "ms-dotnettools.csharp@1.23.16", ],

@jankap
Copy link

jankap commented Jun 15, 2022

This is crucial, anything we can do?

@temparus
Copy link

temparus commented Jul 5, 2022

We use a devcontainer.json to install the extension, would like to put this, but it has no effect:
"extensions": [ "ms-dotnettools.csharp@1.23.16", ],

We had the same issue lately. We got it working in VSCode version 1.68.1 with the following config in devcontainer.json:

{
    "settings": {
        "extensions.autoUpdate": false,
        "extensions.autoCheckUpdates": false
    },
    "extensions": [
        "ms-dotnettools.csharp@1.23.16"
    ]
}

@twodrops
Copy link

twodrops commented Jul 7, 2022

@temparus Are you really sure? It does not work for me with 1.68.1 either.

During the first startup, it installs the specifed extension, but then it autoupdates itself.
Btw, I am testing it from a devcontainer.json. Don't know if this is now only a bug within devcontainer.json.

@temparus
Copy link

temparus commented Jul 7, 2022

@twodrops you're right. It only works properly on the first start of the devcontainer. So, when the container already exists when opening the project in the devcontainer, the auto-update kicks in.

As a workaround, you can add an initializeCommand in the devcontainer.json file to remove the existing container prior to the start of the devcontainer:

{
    "initializeCommand": "docker rm <devcontainer-name>"
}

This enforces that the container is rebuilt on startup. Building the actual container should not take long because the images and build layers are already in the cache.

@Nitschi
Copy link

Nitschi commented Oct 25, 2022

This is critical for us because we need to work with a Python2.7 Codebase and both the Python and Pylance Extension dropped support.

Manually installing the older version is becoming a real pain...

@rafaelkallis
Copy link

We are facing a similar situation where our codebase uses dotnet 3.1 but the official C# extension (https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csharp) does not support 3.1 anymore in their latest relase, hence an older extension version has to be used. (1.25.0 -> 1.24.4)

@vlockhead
Copy link

I am facing the same issue here, it would be nice to be able to specify the extension version in the devcontainer.json the point of running vscode in a docker is to have a known environment

Having to reload re-install the extension manually each time is a pain

@sandy081 sandy081 removed the debt Code quality issues label Dec 12, 2022
@sandy081 sandy081 modified the milestones: Backlog, January 2023 Dec 12, 2022
@joaomoreno joaomoreno changed the title Do not trigger auto updates when a specific version of extension is installed from CLI Support pinning extension version when installed from CLI Dec 13, 2022
@vscodenpa vscodenpa added unreleased Patch has not yet been released in VS Code Insiders insiders-released Patch has been released in VS Code Insiders and removed unreleased Patch has not yet been released in VS Code Insiders labels Jan 13, 2023
@github-actions github-actions bot locked and limited conversation to collaborators Feb 27, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
extensions Issues concerning extensions feature-request Request for new features or functionality insiders-released Patch has been released in VS Code Insiders on-testplan
Projects
None yet
Development

Successfully merging a pull request may close this issue.