-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide official AppImage builds for Linux #10857
Comments
cc @Microsoft/vscode @probonopd This is incredibly cool. I've just watched your presentation on Youtube and everything resonated with me. I admire the work you're doing there, keep it up! @Tyriar Given the huge friction we're seeing with auto-updates on the deb and rpm packages and the crazy benefits this would give us in terms of packaging and incremental updates, I'd be willing to push towards making AppImage our default and recommended distribution method for VS Code alongside a preventive ZIP archive. After a proper investigation, of course. |
Thanks @joaomoreno for your kind words; your PowerShell colleagues are currently also reviewing it for PowerShell distribution. |
By the way, I don't know how applicable this is here, but electron-builder has support for building AppImages for Electron applications too. |
Here are some example AppImages of Electron-based apps that you can download and try:
I could upload one of Visual Studio Code but am uncertain whether the license permits it. |
Go ahead, we are MIT. |
Here is my experimental Visual Studio Code AppImage generated by the script above on Travis CI (build log): https://bintray.com/probono/AppImages/VSCode#files To download and run, simply:
Since the AppImage packaging runs on Travis CI this can be integrated into CI workflows easily. It is expected that some fine-tuning might still be needed, ideally with the help from the upstream team. Known to run on
Does not run on very outdated distributions (to make this work, vscode would need to be compiled on an older build system):
|
It just works, so cool! Thanks for the sample. We will definitely consider this. |
Renamed and added desktop integration (optional installation into the start menu). Download links updated above. |
@joaomoreno are the binaries at https://vscode-update.azurewebsites.net/latest/linux-deb-x64/stable generated by a Travis CI run, and if so, where is the respective code? I could try to hook in there and send a PR which also builds an AppImage using the binaries generated anyway for the deb. |
@probonopd They are generated from our internal build. Building and distributing VS Code is not open source, so you'll have to leave picking this up to us for now. |
Arch Linux user here. There doesn't appear to be a package for my system. Collecting dependencies and compiling is a pain, I'd love to have an appimage. The one linked above seems to no longer exist. |
@GitRASQ the community has put up an AUR package which we recommend. https://aur.archlinux.org/packages/visual-studio-code/ |
I have provided a code-oss Debian package (https://github.com/fusion809/code-oss/releases/tag/debian1.6.1) and built an AppImage from it. |
@fusion809 thanks for your effort but please be aware that only Microsoft can build an official AppImage with the official branding as far as I understand. |
Official branding? What's meant by that? I built an OSS build of code-oss using, the build system that VSCode's official developers put in place. This build is MIT licensed so I can build my own AppImage with it and distribute it, without breaching copyright. |
I don't think this line for example is allowed since the "Visual Studio" branding can only be used in official builds by Microsoft. That's the main reason for the whole "Code (OSS)" vs "VS Code" thing. Same story with the logo. |
I just use the code-oss repo as a place to upload the Debian package, it's does not contain the sources used to build the Debian package. That's used to build an Arch Linux package. |
"code-oss" is fine, it's branding it as Visual Studio and using the logo that could potentially be an issue. |
Some more info on the topic from one of our PMs #60 (comment) |
Well if that's the only problems with my code-oss Debian package I've rebuilt it without any of the MIT license-breakers. Then I built an AppImage and it's working fine. So @probonopd I suspect all is good now and you can provide my AppImage at Bintray. |
@Tyriar any chance you would provide an official AppImage? |
We'll be getting signed apt/yum repos soon, polishing that experience is the priority on this front for now. |
Would you consider merging a PR if I sent one that would generate an AppImage for each continuous build on Travis CI? |
Maybe not related by docker images could help eventually too |
https://flathub.org/apps/details/com.visualstudio.code has it, as does https://snapcraft.io/vscode, with full branding and everything. So I assume we are allowed to do the same in AppImage format?
Source: https://flathub.org/apps/details/com.visualstudio.code
Source: https://snapcraft.io/vscode With AppImage, the VSCode team has the opportunity to distribute the application in exactly the form they like, with full control from the building to the downloading phase. |
What would be needed for the team to reconsider providing an official AppImage build? @Tyriar In the meantime, you can easily make your own using this recipe like this on a Debian/Ubuntu system:
(Debian/Ubuntu system is needed for the conversion from deb to AppImage because the tooling uses apt and dpkg, but the resulting AppImage should be able to run on other systems, too.) Here is the recipe: |
I tried this recipe in KDE Neon with code-insiders_1.33.0-1553235446_amd64.deb package and got this output:
|
The following works for me on
What do you mean by
? The recipe currently gets 1.32.3-1552606978. |
I didn't get it. |
|
I think I get it. This script targets to stable build, not insiders. |
Yes, but you can make a variation of it that downloads and uses the insiders build. |
@probonopd Any idea why Git doesn't work in AppImage? I have tried setting a path, but no luck. |
Please define "does not work". Do you get an error message? |
Well, that's on my work computer, but I think the error message was something like "Git is not installed on your system". I have tried '/usr/bin/git', just 'git' and what not, but I get the same error message. |
Is git installed on your system? |
Yes, working all the time in it. And 'which git' gives me '/usr/bin/git'. |
What is the state of this ticket? I would also like to see an official build for AppImage. The reasons for this is because...
|
No plans to support officially.
I believe this issue was fixed a while ago after we reported it to the snapcraft team #61613 (comment) |
@Tyriar I will try using the snap when I can actually install snaps again... I always use snaps as last resort because I always have so many problems with them. I just opened up an issue for snaps because I can't even install any. https://bugs.launchpad.net/snapd/+bug/1826662 Reason I use AppImage is because I use several linux distros. I use Fedora (rpm based) for work and Ubuntu (deb based) for my home computer. I just had to install vscode using a debian package because snap wasn't working for me. Then on my fedora system I had to install using an rpm because Flatpak (terminal doesn't work in vscode) and snapd had issues for me.. Would be nice if I can just take that one file and run vscode without looking for a deb or rpm which defeats the purpose of these universal formats that we should be moving to. Is there any downsides of doing this? I really hope you can reconsider. |
@chadalen thanks for reporting that, it worked fine for me on Ubuntu 19.04 when I tried last week.
If everyone had their way we would be distributing tarball, deb, rpm, snap, flatpak, appimage and AUR packages. The cost of implementing and supporting all of them is too high. Right now there are community-based options for appimage, flatpak and AUR if you really want to use them over what we provide. Seems fairly simple to use https://github.com/AppImage/pkg2appimage/blob/master/recipes/VSCode.yml and you can see from the source that it's derived from our deb package. |
@Tyriar Ok I see your point. Thanks for your response. |
thanks probonopd ! |
Just for information if you are looking for an AppImage, the VSCodium project is providing binary releases of VS Code without MS branding/telemetry/licensing, including AppImages: |
In the interest of transparency I'm closing this issue as out of scope as we do not plan on implementing this in the foreseeable future and keeping the issue open gives the wrong impression that we may. The primary reasons for closing is that the cost to maintain and support yet another distribution mechanism is too high for too little payoff. You can read more on our issue triaging wiki page on why we close issues. |
I'm happy with the snap on Ubuntu. |
I suggest if we want an app image support we switch to vscodium as they have an official release for appimegs https://github.com/VSCodium/vscodium/releases/tag/1.59.0 |
I agree 100%. We run Fedora SilverBLue and it would be a lifesaver. and @Tyriar appimages can replace deb and rpm builds. |
appimegs are good |
Please provide Visual Studio Code in the AppImage format for Linux. This would allow users to
AppImage is a bundling format for Linux that lets users download one single file, set the executable bit and run the application (here: Visual Studio Code). Unlike other options, AppImage is entirely distribution-agnostic and no special runtime infrastructure is needed on the target system(s). This means that the user can run the application on almost any recent Linux distribution.
It is easy to convert the official deb builds to AppImages using this script.
The text was updated successfully, but these errors were encountered: