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

Persist installed VS Code extensions #13834

Closed
vitaliy-guliy opened this issue Jul 12, 2019 · 8 comments
Closed

Persist installed VS Code extensions #13834

vitaliy-guliy opened this issue Jul 12, 2019 · 8 comments
Labels
area/editor/theia Issues related to the che-theia IDE of Che kind/enhancement A feature request - must adhere to the feature request template. severity/P1 Has a major impact to usage or development of the system. status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach

Comments

@vitaliy-guliy
Copy link
Contributor

Description

VS Code extensions that have been installed by Che Plugins panel must be present/working after restarting the workspace.

VS Code extension is not deployed to Theia while installing. The Plugins panel
offers the user to restart the workspace to apply the changes. This is done intentionally to have the same behavior for VS Code extensions as we have when installing a plugin from plugin registry.

Supporting the separate directory is already implemented in Theia core.
We just forget to specify an environment variable for that in Theia editor component when moved it from che-theia to che-plugin-registry.

@sunix
Copy link
Contributor

sunix commented Jul 12, 2019

We should find a way to persist that in the devfile.
User would expect to be able to get the devfile and share it with his team mate. and having the vscode extensions being installed in the team mate newly created workspace.

@sunix sunix added area/editor/theia Issues related to the che-theia IDE of Che kind/enhancement A feature request - must adhere to the feature request template. team/ide2 labels Jul 12, 2019
@vitaliy-guliy
Copy link
Contributor Author

I see two options here:

  • one is to describe the extension in the devfile like you commented in the PR
    - type: vscodeExtension
      id: 'vscode extension id',
    - type: vscodeExtension
      reference: 'link to the vscode ext binary',
  • another one is to be able to inline content of the plugin meta.yaml in the devfile something like following
    - type: chePlugin
      pluginMetadata:
        apiVersion: v2
        publisher: camel-tooling
        name: vscode-apache-camel
        version: 0.0.14
        type: VS Code extension
        displayName: Language Support for Apache Camel
        title: Language Support for Apache Camel
        description: This VS Code extension provides support for Apache Camel.
        icon: https://www.eclipse.org/che/images/logo-eclipseche.svg
        repository: https://github.com/camel-tooling/camel-lsp-client-vscode
        category: Language
        firstPublicationDate: "2018-04-23"
        spec:
          containers:
          - image: eclipse/che-remote-plugin-runner-java11:7.0.0-rc-3.0
            name: vscode-apache-camel
            memoryLimit: 512Mi
          extensions:
          - https://github.com/camel-tooling/camel-lsp-client-vscode/releases/download/0.0.14/camel-tooling.vscode-apache-camel-0.0.14.vsix
        latestUpdateDate: "2019-07-05"

For me the first one is preferred

@rhopp rhopp added the severity/P1 Has a major impact to usage or development of the system. label Jul 12, 2019
@rhopp
Copy link
Contributor

rhopp commented Jul 12, 2019

If I understand this correctly, we have 3 options for Che 7.0

  1. Do nothing - user will lose all installed plugin with every restart of workspace, if he installed them using Che Plugins panel in Theia. User will still be able to "persistently" install plugins using dashboard & restarting workspace.
  2. Persist installed (by plugins panel in Theia) plugins on volume - This is currently implemented in Separate directory for VSCode extensions che-plugin-registry#180. This will get us into incompatibility in workspace definition (devfile) and the actual state of the workspace.
  3. Persist the plugins in workspace definition (devfile), as suggested by Sun and followed up by Vitaliy in his comment here.

To me personally, solutions 1 and 2 are pretty equally weird - In one user is losing his config, in the second one we have inconsistency, which can cause confusion.
Best one IMO is #3, but it's also the most complicated one.

@l0rd @slemeur What's your opinion on this?

@rhopp rhopp added team/pm status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach labels Jul 12, 2019
@vitaliy-guliy
Copy link
Contributor Author

@rhopp We are talking about only VS Code extensions that has been installed by typing a command into the text field. Any other plugins that have been installed by Che Plugins panel by clicking a button are persisted and will not be lost with restarting the workspace.

@sunix
Copy link
Contributor

sunix commented Jul 15, 2019

@vitaliy-guliy ok at the moment we are installing vscode ext in the theia-ide container but keep in mind that we will eventually allow the user to choose a container where the vscode-ext will run.
If we could optimize the work to have both of them it would be worth it IMHO.

@vitaliy-guliy
Copy link
Contributor Author

@sunix yes, we allow the user to do everything he want by enabling the editing of devfiles. Installing of plugins to any container using Che Plugins panel is another issue

@sunix
Copy link
Contributor

sunix commented Jul 16, 2019

@sunix yes, we allow the user to do everything he want by enabling the editing of devfiles. Installing of plugins to any container using Che Plugins panel is another issue

Let's drop this one, i don't see how that could be useful if we have #13756 ( = Radim's 3. ?) it would be loosing time implementing something that would not be used anymore after #13756.

@che-bot
Copy link
Contributor

che-bot commented Oct 1, 2020

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 1, 2020
@ericwill ericwill removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Oct 1, 2020
@ericwill ericwill closed this as completed Oct 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/editor/theia Issues related to the che-theia IDE of Che kind/enhancement A feature request - must adhere to the feature request template. severity/P1 Has a major impact to usage or development of the system. status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach
Projects
None yet
Development

No branches or pull requests

7 participants