search

microsoft / vscode-remote-release

Visual Studio Code Remote Development: Open any folder in WSL, in a Docker container, or on a remote machine using SSH and take advantage of VS Code's full feature set.
https://aka.ms/vscode-remote
Other
3.66k stars 287 forks source link

Publish Remote - WSL extension to open-vsx #6193

Open frankhuurman opened 2 years ago

frankhuurman commented 2 years ago

I've been using VSCodium instead of VS Code and would love to see this extension added to the open vsx registry https://open-vsx.org so us VSCodium people can use it as well.

Since docker build performance is pretty poor on WSL 2 I would love to try this to see if it speeds up my builds :+1:

isidorn commented 2 years ago

Thank you for opening this issue. At the moment our extension build pipeline is customised to be able to automatically publish to the VS Marketplace. It would require engineering effort to adjust the pipeline to also publish to the open-vsx repository. Currently we have no plans to do this investment, however let's keep this issue open to keep track of this request.

mpql commented 2 years ago

Thank you for opening this issue. At the moment our extension build pipeline is customised to be able to automatically publish to the VS Marketplace. It would require engineering effort to adjust the pipeline to also publish to the open-vsx repository. Currently we have no plans to do this investment, however let's keep this issue open to keep track of this request.

Would it not be relevant to fully embracing the open-source movement to thus embrace use of product functionality by those that choose an open-source route? Containerization is very important to the development-deployment process, and this particular extension is the literal connection between VS Code / Codium and WSL in Windows. This goes for all of the remotes, as in #1925.

I understand this requires engineering effort, and by all means, plan it as you would any other medium-priority feature and get it on a roadmap, but unless I'm misunderstanding, pipeline adjustment is not that high of an investment. In fact, I'm sure the open-source community (myself included) would be more than willing to contribute to that engineering effort if we were able to do so.

I don't mean to be pushy, but I have been waiting for remotes for years -- the entire time I've been using VS Codium, and seeing stale tickets on the matter is incredibly disheartening. Please get this on a roadmap if possible!

isidorn commented 2 years ago

@mpql thanks for your feedback. Can you please help me understand why are you using VS Codium for this scenario and not VS Code? That way I will understand this use case better. Thanks

mpql commented 2 years ago

@mpql thanks for your feedback. Can you please help me understand why are you using VS Codium for this scenario and not VS Code? That way I will understand this use case better. Thanks

Sure. From the repository:

This is not a fork. This is a repository of scripts to automatically build Microsoft's vscode repository into freely-licensed binaries with a community-driven default configuration.

From the website:

Free/Libre Open Source Software Binaries of VS Code

VSCodium is a community-driven, freely-licensed binary distribution of Microsoft’s editor VS Code.

Microsoft’s vscode source code is open source (MIT-licensed), but the product available for download (Visual Studio Code) is licensed under this not-FLOSS license and contains telemetry/tracking. According to this comment from a Visual Studio Code maintainer:

When we [Microsoft] build Visual Studio Code, we do exactly this. We clone the vscode repository, we lay down a customized product.json that has Microsoft specific functionality (telemetry, gallery, logo, etc.), and then produce a build that we release under our license.

When you clone and build from the vscode repo, none of these endpoints are configured in the default product.json. Therefore, you generate a “clean” build, without the Microsoft customizations, which is by default licensed under the MIT license

The VSCodium project exists so that you don’t have to download+build from source. This project includes special build scripts that clone Microsoft’s vscode repo, run the build commands, and upload the resulting binaries for you to GitHub releases. These binaries are licensed under the MIT license. Telemetry is disabled.

The Free / Libre open-source software movement is something I strongly believe in. When given the opportunity to use FLOSS over something proprietary, I do so whenever it's practical. I use Chromium over Chrome because it fits both my ideals and my practices, and I don't want nor need Google collecting telemetry on me. That is not a feature, and I do not wish to have it using my system's resources. I also know what is in the code when I can see the source. I, others -- and I believe Microsoft -- tell people not to run things like batch or PowerShell scripts without knowing what's in them. The running of PowerShell scripts is even disabled by default -- one needs to change the Execution Policy setting first. Why would I want to run a version of something with who-knows-what in it that I have to write special firewall rules for to make it behave the way I want it to? My machine mostly runs the code I want, I don't want to have to fight binaries to get them to function the way I need.

VSCodium is VS Code. It's not a fork. The VS Code binaries Microsoft releases are, in fact, not what one gets from compiling the source here on GitHub. They have things added into it, which is described as "configuration", but amounts to an actual fork. These binaries are then released under a different, non-FLOSS license. None of that works the way open source does or should. The Free + Libre version of VSCode is right here on GitHub. VSCodium simply saves me the work of compiling and configuring these things myself. I would be facing the same issue if I compiled from the source available here on GitHub, because with the remote code being closed, it's breaking on anything other than the closed-source version Microsoft provides. This is the issue, this is the bug that is being reported. If you release the code for the remotes, we'll be able to use it just like we can use VSCode if we compile it.

The situation as it is now is that Microsoft is developing an open-source code base, but closing off important parts of it that allow it to interface with my operating system, which is Microsoft's own Windows. And then you've got WSL2, which lets me run a virtualized Linux machine on its own kernel so I can run Linux commands, but I can't connect the two without having a proprietary software bridge that requires me to use a non-FLOSS version of the first program whose contents are unknown to me, and that it is known to collect data on me to use for profits I neither licensed or see royalties or revenue of any kind from myself -- how does that make sense? Knowing how that works, why would I choose that path? Why would I elect to allow that? Why would I run something whose code I don't have access to?

And what's more, in what I can only interpret as an attempt to be proprietary and lock me into Microsoft solutions, you're actually driving me away from Windows. This process works out of the box on Linux. I don't need WSL or a Remote for it if I can talk to Linux directly. I'm currently staying on Windows for a desktop because Linux does not meet my needs, but Linux is getting better everyday. I am unsure of the benefits of a strategy that adds to the list of needs Windows does not meet, which appears to be what Microsoft has chosen here.

And again, while it'd be best if you all fixed this issue, I know that's asking a lot. Regarding engineering effort, the open-source community would make it work if needed -- you'd just have to fully follow through on the open-source commitments made thus far with VS Code. We're not asking you to open source a proprietary product, we're asking you to open the source for the rest of a product that you call open-source. Otherwise, this thing that purports to be free, open-source software is more like shareware with important functions like Remotes locked behind paid premium plans -- and the payments are my data, my use of a fair and free license, and my knowledge of the code running on my machine.

My use case is running the open source code of a project that is presented to me, and it's not working out of the box with a good compilation. My use case is not wanting my data collected without my consent, used for unknown and undisclosed purposes, and not seeing any royalties from the profit of the sale thereof. My use case is connecting the development app I use to the operating system I use.

A huge part of open source is you can run the code you see yourself, just like I can run a batch or PowerShell script. Would you willingly run a PS script that somehow prevented you from being able to see what's in it when an open one purporting to be the same thing existed? Running your code as you have here on GitHub doesn't work; the issue isn't VSCodium, it's the proprietary nature of parts this code.

I hope that helps, please let me know if you have any questions. And please open source the code for the VS Code Remote extensions.

EDIT: Edited for clarity 2022-06-18

KaspianDev commented 2 years ago

@mpql thanks for your feedback. Can you please help me understand why are you using VS Codium for this scenario and not VS Code? That way I will understand this use case better. Thanks

I don't use vs code because it is not free software. Nothing will make me use it.

bevsxyz commented 1 year ago

Dear extension author, Please publish this extension to the Open VSX marketplace.

Context

Unfortunately, as Microsoft prohibits usages of the Microsoft marketplace by any other products or redistribution of .vsix files from it, in order to use VS Code extensions in non-Microsoft products, we kindly ask that you take ownership of the VS Code extension namespace in Open VSX and publish this extension on Open VSX.

What is Open VSX? Why does it exist?

Open VSX is a vendor neutral alternative to the MS marketplace used by most other derivatives of VS Code like VSCodium, Gitpod, OpenVSCode, Theia-based IDEs, and so on.

You can read on about Open VSX at the Eclipse Foundation's Open VSX FAQ.

How can you publish to Open VSX?

The docs to publish an extension can be found here. This process is straightforward and shouldn't take too long. Essentially, you need an authentication token and to execute the ovsx publish command to publish your extension. There's also a doc explaining the whole process with an example GitHub Action workflow.

This is the issue template from openvsx. https://github.com/open-vsx/publish-extensions/blob/master/docs/external_contribution_request.md

KaspianDev commented 1 year ago

Dear extension author, Please publish this extension to the Open VSX marketplace.

Context

Unfortunately, as Microsoft prohibits usages of the Microsoft marketplace by any other products or redistribution of .vsix files from it, in order to use VS Code extensions in non-Microsoft products, we kindly ask that you take ownership of the VS Code extension namespace in Open VSX and publish this extension on Open VSX.

What is Open VSX? Why does it exist?

Open VSX is a vendor neutral alternative to the MS marketplace used by most other derivatives of VS Code like VSCodium, Gitpod, OpenVSCode, Theia-based IDEs, and so on. You can read on about Open VSX at the Eclipse Foundation's Open VSX FAQ.

How can you publish to Open VSX?

The docs to publish an extension can be found here. This process is straightforward and shouldn't take too long. Essentially, you need an authentication token and to execute the ovsx publish command to publish your extension. There's also a doc explaining the whole process with an example GitHub Action workflow.

This is the issue template from openvsx. https://github.com/open-vsx/publish-extensions/blob/master/docs/external_contribution_request.md

mikrusoft probably doesnt give a f. best idea is to just move on and find an alternative.

Authors: dont publish on m$ "official" marketplace. The better way to fight a monopoly would be to boycott it entirely.

trinitronx commented 1 year ago

Another +1 for this request.

@isidorn It seems like it's pretty simple to implement dual publishing via a GitHub Actions workflow described here. It probably wouldn't take very long to accomplish.

For better or worse, there currently exists a rift in the ecosystem due to the aforementioned licensing issues (whether they be actual or simply perceived ¯\_(ツ)_/¯ ). This split between the VisualStudio Marketplace and OpenVSX remains a common source of confusion for new *nix users who simply wish to install and use VSCode like they do on other OS's. They might wonder why some extensions they are used to using appear to not exist. They also may wonder why Settings Sync doesn't appear to work (without patching product.json in the installed files).

I'm not a lawyer, so it's not clear to me what the legal details are... but it seems logical that any MIT or FOSS-compatible licensed extensions could be dual-published without restrictions.

@mpql thanks for your feedback. Can you please help me understand why are you using VS Codium for this scenario and not VS Code? That way I will understand this use case better. Thanks

Whether we like it or not, the MS-published official VSCode packages only support .deb, .rpm, and Snapcraft packages. Which limits their utility on *nix distros that don't use those package managers natively. Therefore, there's a barrier to using official MS VSCode even if we wanted to on other systems. Meanwhile, VSCodium / code-oss packages are readily available thanks to the fully OSS license.

So, in order for most Linux developers using stock OSS-packaged versions of VSCode to find extensions such as this one, it's important to also publish to OpenVSX.

I'm sure there are also others who would love to use this extension but currently can't find it due to the split between OpenVSX / VisualStudio Marketplace repos for OSS builds of VSCode. In the past few years, many OSS Linux packagers of VSCode, VSCodium, (a.k.a. Code OSS) have moved to using OpenVSX extension Registry and had to disable VisualStudio Extensions Marketplace by default due to Microsoft's aforementioned licensing restrictions.

Always-Self-Hosted commented 7 months ago

@mpql thanks for your feedback. Can you please help me understand why are you using VS Codium for this scenario and not VS Code? That way I will understand this use case better. Thanks

Can I also ask for you to help us understand why Microsoft is building out features for an open source core product that are not open source and are design in a way to not function with the open source core? This is a genuine question, because I 100% believe the reason is not based on monetizing features (how could it be, vscode is free after all) but I genuinely do not understand the reason?

githubuser6000 commented 6 months ago

@mpql thanks for your feedback. Can you please help me understand why are you using VS Codium for this scenario and not VS Code? That way I will understand this use case better. Thanks

The usecase here is to get away from an editor and an ecosystem, that at every step, seems to advertise to me to use one more microsoft service (github accounts, codespaces, tunnels, hosted environments, copilot being the egregious offender - why was it automatically installed?), enough to vendor-lock me into the ecosystem. I am already seeing this SO much at work.

I have grown tired of microsoft's pushy and distasteful, put mildly, practices. So much so, I've

I thought microsoft actually was turning over a new leaf and doing something useful in open source for once. But no, the corporate greed clearly shows. Take all contributions of contributors for free, package it up, and sell it yourself, and prevent others (say, the devs themselves) from making any use of it. Case in point - the pythton extension too

I understand perhaps this isn't something you control, and I get that. All I ask for is that microsoft drop the facade and tell things as it really is. vscode isn't "OSS". I hope microsoft closes this issue as "not planned", because that's the fact of the matter as posted in the FAQ. Send a clear message. This thread and similar threads have been going on for years. Nip the bud of hope at the roots.