Hi, I’m really sorry as you probably get this question all the time, but I still don’t quite understand the recommended way to consume an (open source, free, VSCode, not-mine) extension in Theia. From reading the various articles it seems that you used to connect directly to their marketplace, they kicked you off, now you have your own marketplace, but there’s nothing on it. I don’t know whether as an individual I could publish someone elses extension to openvsx, but that seems like a weird thing to do plus if that were possible I’m guessing you’d already have cloned them all over? So do I (clone/publish it to openvsx myself) or (clone it to my own repo/filesystem or something and somehow directly consume it in Theia via github/filesystem)?
@FalseProtagonist thank you for the discussion, I’ll try to clarify a few things:
From reading the various articles it seems that you used to connect directly to their marketplace
We never directly interfaced with the marketplace, extensions were previously downloaded (outside the framework) and placed in a directory from which they can be consumed.
they kicked you off
but there’s nothing on it.
I’m not sure what you mean by “there’s nothing on it”, there open-vsx marketplace already includes a number of the most popular extensions.
if that were possible I’m guessing you’d already have cloned them all over.
It is not feasible to clone and publish all extensions under the marketplace. There are licensing issues which may exist, and namespaces to respect. If an extension is desired to be a part of the marketplace you can view the documentation on how to do so.
So do I (clone/publish it to openvsx myself) or (clone it to my own repo/filesystem or something and somehow directly consume it in Theia via github/filesystem)?
In order to consume extensions as part of your custom application you should include the necessary
@theia dependencies (such as the plugin-system and vsx-registry). The
@theia/vsx-registry allows you to view and install extensions from
open-vsx. Alternatively, you can define your
builtin extensions you’d like included in your custom application by defaulyt by defining them in your
package.json of your application similarly to our upstream example: https://github.com/eclipse-theia/theia/blob/master/package.json#L85
Thanks a lot for the reply. Sorry I was a little loose in my language, your corrections are mostly things that I somewhat understood but stated imprecisely.
I still don’t fully understand the recommendation here in this case - if there’s possible licensing and namespacing issues (beyond my ken), I guess it’s not recommended for me to try and push someone elses repo up onto openvsx.
Taking a concrete example for my slowness:
So if I understand, it’s illegal for me to download the vsix file and use that, not recommended for me to start trying to publish things to openvsx, and AFAIK not possible to consume the github directory directly
I’m sure I’m missing something here for how I consume the extension then. The only thing I can think of is running my own extension-hosting server and publish to that, but that seems quite heavy to change a theme.
Edit: or use your tool to create a VSIX that I store (as binary?) in my own github repo, I guess that’s the simplest possible solution? But the docs don’t push one towards that.
@FalseProtagonist if you want to consume the extension as part of your application, then you will either need to:
- publish the extension to open-vsx from which you can consume it (there’s more info here about namespaces). You are able to publish the extension without owning it given that the extension itself has a open license. (warnings will be shown on open-vsx in the case that there is no ownership claim yet).
You can alternatively fork the repository, package it, and publish it as a GitHub release.
This will allow you to add the extension as part of your application (if defined in your
package.json) but will now allow your users to add it themselves through the
extensions-view which interfaces to
guess it’s not recommended for me to try and push someone elses repo up onto openvsx
You’re pushing their repo, you’re only hosting their packaged extension for others to consume.
This is described in the open-vsx wiki for additional information.
Ok, so if I understand the options are: openvsx, or push a binary to my own github.
I just read the namespace documentation, it describes the mechanics of ownership but not the intended social norms/best practices, which is kind of my question.
It sounds like you’re saying (license-dependant), that it’s not considered so crazy to package someone elses extension. But then what namespace would be recommended, their equivalent VScode namespace, and add them as admin? Is there some standard “the owner hasn’t claimed this yet” namespace? (edit, that’s publically usable). That would seem cleaner than moving everything across adhoc under random namespaces only to possible be moved again later.
You can see my question I hope - any approach/social norm simple enough for me to understand and implement would seem to be simple enough to script and do a mass import.
A bit of context:
The open-vsx.org registry is bootstrapping, slowing gaining in content and users. There is, at first, little incentive for vscode extensions authors to publish to a new registry that’s used by almost no one. When it starts to grow, some authors notice and want to make sure their extension(s) are built and published correctly, so they claim their namespace and actively publish new versions. We have a few important namespace owners who have already done so, including “redhat”. But realistically it’s impossible to recruit all of them, though ideally every extension would be published by its original author.
It sounds like you’re saying (license-dependant), that it’s not considered so crazy to package someone elses extension.
This is the quickest, most straightforward way to get an extension on open-vsx.org, that’s not there already, if its namespace is not restricted.
However, there is an alternative I recommend instead, that insures the extension is built by a trusted, neutral 3rd party, so everyone can trust that it was not tempered-with (vs "built by
$ramdom github_handle" ):
Extensions so published appear under their original namespace, published by user
open-vsx. For example:
So, I suggest opening an issue in their repo, and if you can and would like to speed things up, add the extension yourself in a Pull Request. Then it will be automatically handled, with both solid revisions and nightly builds, automatically built and published.
But then what namespace would be recommended, their equivalent VScode namespace, and add them as admin?
Generally you do not want to change the namespace of a vscode extension, so yes, you’d keep the original namespace. This will insure that this extension, if it’s depended-upon by other extensions, will be found. Another case are vscode extension packs, that depend on the listed extensions being found/fetched, at install-time, by
<namepace>.<name>. e.g.: https://github.com/microsoft/vscode-java-pack/blob/master/package.json#L142-L149
No need to add the “real” owners as admins - any namespace owner can claim it, if they care to do so, and take-over, without your intervention.
Thanks so much for the detailled reply, I appreciate it- sorry if my question was a little blunt.
I saw that this admin user existed in the namespace doc but did not appreciate the mechanism/possibility of hooking into the extension-publishing mechanism, I think because I don’t contribute to open source and saw the word “admin” my corporate brain assumed it was closed.
Hopefully this thread helps someone else.
@vince-fugnitto, just to make sure I got everything right - let’s say I download a VSIX of a plugin with an open license (say, MIT), put it in my
plugins directory from which I consume plugins in my Theia application and bundle everything together so that my app has this plugin as a built-in plugin. Am I allowed to do that or do I need to go through the steps described above?
Up until now, I was sure that it’s ok but now after reading this thread I’m no longer certain.
Thanks for your reply.
@mnaglic it should be fine, it is similar to the
download:plugins option which is a helper script to list and download plugins as defined in the
package.json. If you manually perform this step it is fine as well.
Great, thank you!