search

eclipse-che / che

Kubernetes based Cloud Development Environments for Enterprise Teams
http://eclipse.org/che
Eclipse Public License 2.0
6.99k stars 1.19k forks source link

Allow VS Code plugin broker to download extensions from a custom location #12549

Closed tolusha closed 5 years ago

tolusha commented 5 years ago

Description

While working on deploying the VS Code extension as a remote plugin I faced the case that isn't covered by the current VS Code plugin broker [1] behavior. It deploys a plugin only when if it is located at the marketplace.

My case is the following: VS Code contains some built-in extensions (for instance the typescript extension [2] ) and it isn't at the marketplace. What if this broker has functionality to download an extension not only from the marketplace but an archive from a custom location? In this case it is possible to clone the extension, compile, pack and host somewhere if it was the marketplace [3].

Suggestion

attributes might contain either extension with identifier or url to the extension.

attributes:
  extension: "vscode:extension/ms-vscode.node-debug2"
attributes:
  url: "http://some.location"

[1] https://github.com/eclipse/che-plugin-broker [2] https://github.com/Microsoft/vscode/tree/master/extensions/typescript-language-features [3] https://marketplace.visualstudio.com/vscode

Related issue

https://github.com/theia-ide/theia/issues/3767

tolusha commented 5 years ago

/cc @garagatyi @l0rd @tsmaeder

garagatyi commented 5 years ago

@tolusha we already have field url on the same level where the attributes field is. You should reuse this field instead of adding a new one. Can you describe what would be the packaging of such an extension and what it contains?

tolusha commented 5 years ago

The current structure of the vscode extension from the marketplace is the following:

extension
[Content_Types].xml
extension.vsixmanifest

So, how am I going to prepare this archive?

  1. Extension folder contains compiled code from [1]
  2. Copy all needed dependencies into extension/node_modules
  3. Copy prepared files [Content_Types].xml extension.vsixmanifest

[1] https://github.com/Microsoft/vscode/tree/master/extensions/typescript-language-features

garagatyi commented 5 years ago

Are you going to package it as a zip archive?

tsmaeder commented 5 years ago

If the broker already allows for giving a url for the archive, why is this not working out of the box? It should as far as I understand it.

garagatyi commented 5 years ago

@tsmaeder That URL is used by other brokers implementations (we have several brokers, not just one). In particular Theia broker (supports URL to a .theia file) and Che common broker (URL to tar.gz archive with binaries and sidecar configuration). Meta.yaml model contains fields that can be used by several types of brokers.

tsmaeder commented 5 years ago

Yes, but I'm just talking about the vscode broker.

tolusha commented 5 years ago

Are you going to package it as a zip archive?

yes

Yes, but I'm just talking about the vscode broker.

vscode brocker doesn't use url

tsmaeder commented 5 years ago

vscode brocker doesn't use url

maybe it should? What's the advantage of going through the marketplace info (instead of giving a direct url) except we have to type less?

garagatyi commented 5 years ago

maybe it should? What's the advantage of going through the marketplace info (instead of giving a direct url) except we have to type less?

Do you mean changing the current approach to use url like https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint instead of plugin identifier like vscode:extension/dbaeumer.vscode-eslint?

tolusha commented 5 years ago

No, I guess either url or plugin id

garagatyi commented 5 years ago

It was a question to @tsmaeder

tsmaeder commented 5 years ago

Yes, that's what I meant: it might also allow us to reference a particular version of the vscode plugin, not "latest".

garagatyi commented 5 years ago

We could implement this. But, in this case, we would have several cases when URL might mean something different:

BTW how to get a link to a page of a non-default version of an extension? I haven't found.

tolusha commented 5 years ago

BTW how to get a link to a page of a non-default version of an extension? I haven't found.

Probably there isn't. So, any particular concerns?

garagatyi commented 5 years ago

Just thinking about the case with several versions Thomas has mentioned

l0rd commented 5 years ago

@garagatyi we don't need to solve the problem of different versions right now. We can solve @tolusha problem first. It totally make sense to me.

Can't we just use the url attribute instead of using attributes#extension? And url in the case of a VS Code extension should always point to a vsix file.

garagatyi commented 5 years ago

@l0rd I'm OK with the approach suggested by @tolusha. Just exploring what Thomas is suggesting. It is way trickier to get VSIX URL from the marketplace than the just ID of the extension. I would leave the flow like it is now not to make ppl parse very nested JSON from marketplace API. At the same time usage of extension ID or url to the marketplace page allows us to implement usage of custom version later

l0rd commented 5 years ago

@garagatyi makes sense thanks for these details