Plugin Installation UX

[slemeur]

User Story

As a user I should be able to easily configure the plugins used in my IDE, so that I can quickly see the tools that are available and choose new ones corresponding to my needs in the workspace.

Description

We are already providing a "plugin" panel, which allows the user to see the list of plugins that are enabled for the workspace. We should extend the capabilities provided by the plugin in order to allow the user:

• see the complete list of all available plugins
• see the list of plugins that are enabled
• allow to enable/disable a plugin

The list of all the plugin available in the various broker will be displayed and sorted alphabetically.

We should also make take that opportunity to simplify the experience to install a VSCode extensions. In order to do that, we should provide a header at the top of the list which will provide a button "Install VSCode Extensions". It will call the command palette and the action to install a plugin.
We will need to allow the user to provide either the plugin ID or the URL of the plugin on the marketplace.

Follow-up iterations ideas

• We could allow to filter/sort the list:
  • by broker
  • by installed/uninstalled
• We could provide options to open the plugin's markdown and documentation
• We could allow to browse the list of VSCode extension directly from the IDE

Sub-tasks

Must have

• List all the plugins available accross the plugin registry
• Display indicator about installed/not installed
• Give ability to the user to proceed installation/uninstallation
  • Display visual feedback when a plugin is getting installed
  • Display notification when a plugin has been properly installed
  • Provide way to see errors if that happens
• Dedicated list for the installed plugins
• Postponed: Filtering plugins by name, etc.
• Postponed: Display information about the plugin in editors section?
• Postponed: Display built-in plugins (provided by docker image)
• Postponed: Add ability to disable/remove default plug-ins in Che Theia che-theia#159
• Provide ability to easily add a VSCode extension
• Display editors in separate list

[sunix]

Hello,
We (IDE2) are debating about this issue and we have different opinions about if this feature should be implemented as part of a Theia extension or a Theia plugin.

I would like to have your input (especially @l0rd and @benoitf ones)

I will try to consolidate the discussion:

Pro Theia extension:

• In the future, we will handle dynamic plugins installation. It will not be possible to manage dynamic installation of Theia plugins from a Theia plugin.
• Replacing default Theia plugins view. It is not possible to replace/override the default Theia plugins view from a Theia plugin.
• Security ? would we allow plugins to manage plugins could be a security issue?
• If we start to do it as a plugin and figure out later on that it is not possible, we would have to move that as a extension ... so let's do it as an extension
• Already started doing it with as an extension ... let's finish it and have something done quickly for Che7 GA and move it afterwards to plugin.

Pro Theia plugin:

• If it is possible to do that in a plugin, why not ?
  • It is possible to implement what we had plan in the next sprint as a plugin
  • About dynamic plugins installation, We will find a way to have that as a plugin. We could also mix plugin and ext like we do for Che API. But we are not here yet... Let's make it by iteration in an agile way.
  • We had that rule: if you can do it with a VSCode extension, go for a for it first, if not, go for a Theia plugin, if not go for a Theia ext ....
• Replacing default Theia plugins view. the default Theia plugins view could be extracted from plugin-ext to another 'plugin-ext UI' extension and then be excluded from our assembly.
• We would have a better development flow when working on this part. Not having to rebuild the entire che-theia but just the plugin.
• If we start to do it as a extension and figure out later on that it is possible to do that with a pugin, we would have to move that as a plugin ... so let's do it as a plugin
• It was a pain to move all the extensions to plugins and we are restarting that again ? The sooner we do it in the right way the better.

Thoughts ?

[vitaliy-guliy]

I would prefer to have plugin management system in extension.
As for me it's reasonable to manage plugins from the core part, not from the other plugin.
And yes, we can extract existing plugins view from plugins-ext to dedicated extension and exclude this extension at all if necessary.

[sunix]

Installation is done either by the broker (for che-plugins) and/or Theia "core" (just the theia plugin part), but what if we want the same UI on the dashboard ... it should be possible ... These are mainly UX/UI and these UX/UI has nothing to do with the "core part" which are managing plugins. It makes sense to decouple these things.

[l0rd]

For what is worth I am +1 for the extension. Mainly because I think we have been a little too far with "everything should be a plugin". If it has been started as an extension let's be pragmatic and keep it as an extension. I don't really buy the "swappable plugin viewer" feature: users may want to customize a lot of things but why should they want to change the plugin viewer?

[sunix]

@mario it is not about 'everything' should be plugins, but when nothing is stopping that to be a plugin, we should go for plugin. Plugin is also simpler to code and maintain.

[sunix]

Provide ability to easily add a VSCode extension

IMHO, we should detect remote theia runtimes that are installed and be able to choose one of these runtimes when adding a VSCode extension
@l0rd @slemeur WDYT ?

[slemeur]

what "detecting remote theia runtime" means in your mind? What do I need to choose?

[sunix]

OK, the Theia container has the minimal set of dependencies .... it is very limiting, but maybe some extension would just need java8 and if he has already a remote runtime with java8 that could host any VSCode extensions, it would be nice if user could select it instead of the default Theia container runtime.
Then maybe we could provide a marketplace of runtime to choose from ...

[slemeur]

No need to ask the user. The user should not worry about "where the plugin is running" - we should be handling that for him.

[sunix]

but if the VSCode extension doesn't work because of missing dependencies in the Theia container ? how could we magically handle that for him ?

[slemeur]

OK, so you are in the context of a VSCode extension which is not in the registry and which is having dependencies:
We should have a proper error message, to inform the user that the extension can't be installed and why. Then point him to the documentation on how to make the VSCode extension compatible with Che and add it to the registry.

Let's first "fail properly" and see later on how we can better handle the situation.

[sunix]

I am not sure we can detect that kind of problem easily, and fail 'properly': Maybe we would have an error from the extension itself at runtime, like Java 8 is required to run this extension, please download and install the it from ... That would help in the VSCode context, but not Che.

[sunix]

Provide ability to easily add a VSCode extension

IMHO, we should detect remote theia runtimes that are installed and be able to choose one of these runtimes when adding a VSCode extension
@l0rd @slemeur WDYT ?

We agreed that in a first iteration, we let the user provide the URI of the vscode extension to install. Extension would be installed in the Theia container

[che-bot]

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.