Integrate with open-vsx.org

[felipecrs]

Hi,

Open VSX was just released and it is a open source registry for VS Code extensions, just like Visual Studio Marketplace.

It may be a good idea to use and support Open VSX instead of creating yet another one, since the extension developers will have more places to publish.

It's just an idea.

https://open-vsx.org/
https://github.com/eclipse/openvsx

[nhooyr]

We are reviewing this internally.

[kylecarbs]

After internalizing this, we've decided to not do this.

We'll likely document our registry more-heavily in the future. For now, if we switched over we'd lose a lot of extension support.

[felipecrs]

It's perfectly understandable from a company's point of view.

However, for consumers (developers in general) of code-server (or any other "distribution" of VS Code other than Microsoft), a single registry for vsix would be good because it would have a better chance that an extension is there and also updated. And mainly for the extension developers, because they would not have to push to different places, which is hard to maintain.

The ideal world would be to see you guys working together with @TypeFox (a company that has been working in openvsx) in favor of a single and greatest vsix registry.

But this is just my thoughts. I hope both registries to grow so 😎.

[nhooyr]

@meysholdt Hello Moritz!

Congrats on openvsx. How many extensions do you guys have in total on there in comparison with the VS Code marketplace?

[meysholdt]

Hi @nhooyr, thank you!

I'll forward that question to @spoenemann, who is leading the OpenVSX project at TypeFox.

[spoenemann]

The registry is still in testing / "beta" status and we are in the process of transferring open-vsx.org to the Eclipse Foundation (the source code is already an Eclipse Foundation project, but the public deployment is currently operated by TypeFox). I hope we'll get this transfer done within a few weeks.

You can now see the number of extensions below the search field (194). That's of course very little compared to the Microsoft Marketplace (17582), but that's also because we haven't put any work in promoting the registry yet (apart from an Eclipse Newsletter article).

[nhooyr]

You can now see the number of extensions below the search field (194). That's of course very little compared to the Microsoft Marketplace (17582), but that's also because we haven't put any work in promoting the registry yet (apart from an Eclipse Newsletter article).

That's a showstopper for us. What do you think of using our registry which is presently at 4184 extensions? We'd be happy to open source and donate it. It's written in Go and runs on kubernetes. It scrapes a manually collected list of GitHub repositories on which extensions are hosted but also allows submitting VSIXes manually.

We just don't have a public frontend for it to submit extensions yet #1299

[mahmoudajawad]

Yes! do it! That would be great for the FOSS community and for both the teams.

[nhooyr]

Hi @spoenemann, any update on my proposal? It's best for the community that we work together on this rather than apart.

[felipecrs]

I see conceptual divergences in the two.

code-server registry searches the internet for .vsix files, this way, extension developers have to do nothing. It's good it already has so many extensions.

openvsx aims to be a full replacement for VS Marketplace, which even provides a CLI for publishing extensions, so developers have to publish in both VS Marketplace and OpenVSX. And that's not a problem: Marketplace for VS Code users and OpenVSX for everything else. With time, it can become a standard for extension developers.

A mix between the two concepts sounds interesting: I don't know if Microsoft will publish their own extensions in OpenVSX on their own, then the code-server approach is a fallback.

[nhooyr]

@felipecassiors That's besides the point. Ideally we have a single open source extension marketplace otherwise we're going to end up competing with each other. As of now, we have dramatically more extensions thanks to our approach. We can merge the two thoughtfully if we work together.

[felipecrs]

I updated my comment btw, but yes, you're right. Merging the two somehow would be the best.

[spoenemann]

Hi @nhooyr! I would appreciate having a common marketplace instead of two separate ones, too. The main reason holding me back from your proposal of using your registry is that we are in the process of moving open-vsx.org to the Eclipse Foundation. That includes operations as well as the Terms of Use, Publisher Agreement etc. We will likely have restrictions on the types of open source licenses that will be accepted for published extensions. With this background, having already thousands of extensions in the registry rather makes the migration process more complicated.

Submitting to a strong open source foundation like Eclipse comes with additional requirements and restrictions, but IMO it's totally worth the effort. Having a marketplace that is not controlled by one single company, be it Microsoft or TypeFox or Coder, but rather a vendor-neutral organization would be very beneficial for the VS Code extension community in the long run.

[nhooyr]

The main reason holding me back from your proposal of using your registry is that we are in the process of moving open-vsx.org to the Eclipse Foundation. That includes operations as well as the Terms of Use, Publisher Agreement etc. We will likely have restrictions on the types of open source licenses that will be accepted for published extensions. With this background, having already thousands of extensions in the registry rather makes the migration process more complicated.

I get it, we can revisit after it's accepted by the foundation.

Regarding licensing, it shouldn't be very difficult as all the extensions on our marketplace are open source and include a proper license.

[nhooyr]

Submitting to a strong open source foundation like Eclipse comes with additional requirements and restrictions, but IMO it's totally worth the effort. Having a marketplace that is not controlled by one single company, be it Microsoft or TypeFox or Coder, but rather a vendor-neutral organization would be very beneficial for the VS Code extension community in the long run.

Preach!

[decalek]

@spoenemann, @nhooyr, As a practical step towards the merger, I think we could start to clear technical details like common schema, conversion, verification queries, etc, during the transfer completion suspense.

Do you mind, to start dumping the two databases to something versioned like DoltHub from time to time?

(IMHO, cloneable/queryable open-data style interface to the metadata could be in favor to the extension contributors in general)

[spoenemann]

An update on the current state of open-vsx.org: The transfer to the Eclipse Foundation will happen by the end of this year, announcements will be distributed soon. From that point on, the Foundation will be responsible for this service. If you are interested in a collaboration, I suggest you get in touch with @brianking about it.

[oxy]

Now that the Eclipse transition is complete, we're taking a second look at making a transition to Open-VSX happen! For now, I plan to start reaching out to developers to try and convince them to list their extensions on the marketplace, and failing that, I'll try to add their extensions via the alternative open-vsx CI: https://github.com/open-vsx/publish-extensions

I'll see what I can do in the next weeks!

[brianking]

@oxy This is great news! We are currently reaching out to existing Open VSX publishers to ensure they are compliant with recent changes, so if you need help with your messaging let me know.

https://blogs.eclipse.org/post/brian-king/open-vsx-registry-under-new-management
https://blogs.eclipse.org/post/brian-king/new-era-open-vsx-registry

[oxy]

Hi! Currently I see one major pain point for the migration so far; extensions with different names due to either

1. Replaced components; for example ms-dotnettools.csharp is muhammad-sammy.csharp because they replace MS' proprietary debugger with Samsung's open source one
2. Changed maintainership; for example, we list a robinbentley.sass-indented but maintainership has moved and the OpenVSX extension is syler.sass-indented

Is there an obvious way to tell users about these changes/smooth out migration?

[nhooyr]

To echo what @oxy is saying, ideally I think we'd extend the query protocol to allow indicating whether an extension name is an alias for a different extension on open-vsx and then we could modify code-server to make that clear in the UI that when you searched for X but got Y, that's because Y is the equivalent on open-vsx.

[brianking]

I don't know if we would necessarily have all that cross-reference information in our DB, so some of it would be inferred thus imperfect.

@spoenemann Can you think of a good solution for this?

[oxy]

I will most likely be manually cross-referencing all the extensions we have and then documenting them in Google Sheets - just not sure if there's a way to have redirects or something similar on open-vsx, and would appreciate any docs or something to that effect!

[spoenemann]

We have put a lot of effort to enable reusing the same extension IDs as the VS Code Marketplace. The two cases you mentioned are "naturally grown" by the community of publishers.

Note that Microsoft's C# extension cannot be used in Coder nor any other non-MS tool:
https://github.com/OmniSharp/omnisharp-vscode/blob/master/RuntimeLicenses/license.txt

[oxy]

Ack, double send! My browser seems to be dieing today :(

[RandomFractals]

@oxy where is your cdr extensions registry hosted currently?

I wanted to see if my extensions are there b/c honstly I don't think I am ok with you guys using them since your platform is not free.

[5hay]

Is there anything new to say about the transition to open-vsx.org? Some extensions are very outdated, e.g. Foam (not the case on open-vsx.org).

Is there any way I can change the URL myself and point code-server to open-vsx.org?

[bpmct]

Is there any way I can change the URL mysql and point code-server to open-vsx.org?

@5hay yep, you can do this today. See https://github.com/cdr/code-server/blob/main/docs/FAQ.md#how-do-i-configure-the-marketplace-url

[5hay]

@5hay yep, you can do this today. See https://github.com/cdr/code-server/blob/main/docs/FAQ.md#how-do-i-configure-the-marketplace-url

@bpmct thank you for the very fast reply. I've already tried that, but unfortunately it doesn't seem to have any effect. It still connects to "https://extensions.coder.com/api/extensionquery" and the searched extensions are still the old versions (another example: "Markdown All in One" - should be version 3.4.0, but is only 3.0.0).

/edit:

Okay, let's just say it was a long work day 😀 I was setting these env vars after the Docker container was created (in the container itself). The trick is to set them before creating the Docker container (e.g. in the docker-compose.yml file).

Thank you very much for the help, have a great weekend everyone.