Sorry to tell everyone but I currently won't maintain this repo anymore

[amtlib-dot-dll]

@nedrichards @TingPing @barthalion @alexlarsson @ebassi @jurf

I have recently graduated from campus and found a job, and I don't have much spare time as before. Missing my school days.

This repo consists of a Python script generating a JSON recipe. Though not fully documented, the symbol names should be pretty self-explanatory.

Feel free to ask me about any further questions about it. I will check my GitHub inbox irregularly.

Wishing volunteers for our project and our dream for free softwares!

[barthalion]

I don't think there will be many people happy to pick up maintenance so it should be marked EOL and probably set end-of-life-rebase to regular VS Code.

[G-Ray]

Thank you for all the time you have spent on this project @amtlib-dot-dll !

Even if this project (and vscodium) is a step towards a more free software than official vscode binary, as long as these projects still rely on the microsoft marketplace it can't be really "libre".

It would be awesome if a team would create a true libre project based on vscode, with a reimplementation of the marketplace's backend which would only contains libre extensions.

[HarryMichal]

Isn't this a great opportunity to become official flatpak of VSCodium[1]? I can try to set it up.

[1] https://vscodium.com/

[G-Ray]

Exactly @HarryMichal, you can start by forking the official vscode from flathub repo (https://github.com/flathub/com.visualstudio.code). I started to work on it but did not have much time for now

[amtlib-dot-dll]

Good deal @G-Ray and @HarryMichal! By the way I'd like to remind you that the building process requires network isolation, and therefore a lot of work of the current recipe is to pre-calculate the dependencies. @barthalion Would there be any exception for that?

[HarryMichal]

I'll try to put something together ASAP but I'm not 100% sure when that'll be. I'll take a look at the repo @G-Ray, thanks.

[gasinvein]

Hello everyone. I'd like to revive VS Code OSS on Flathub, but the build system of this flatpak feels way too complicated, at least for me. So I've made it almost from scratch, without any custom manifest generation scripts involved; instead, the flatpak-node-generator.py script does all the hard work. If anybody interested, have a look at the new manifest.

[TingPing]

@gasinvein I've given you access, have at it :)

[gasinvein]

@TingPing Honestly, I'd rather like to submit a new app with different ID (.code-oss instead of .code.oss). There are multiple reasons to do so:

• code-oss is the actual base name that MS uses for OSS builds (e.g. it's icons and .desktop files)
• This makes sure we don't clash with user data from existing installations (which might be incompatible)
• It is an entirely different flatpak build, and I don't want to just replace @amtlib-dot-dll's work with mine

[TingPing]

It is an entirely different flatpak build, and I don't want to just replace @amtlib-dot-dll's work with mine

This is irrelevant. Its just a package.

If the app-id is different upstream, and I mean it actually is fully com.visualstudio.code-oss, then thats fair. It should still be rebased automatically to the new app.

[Croydon]

Would there be any differences to https://flathub.org/apps/details/com.vscodium.codium ?

[gasinvein]

@Croydon AFAIK vscodium is just a binary build of vscode-oss. So, the vscodium flatpak repacks those binary builds, while this flatpak (and so does mine) builds it from source. That said, you should ask vscodium maintainers how their builds differ from VS Code builds from original source.

[gasinvein]

@TingPing I didn't notice MS using reverse-dns notation in VS Code OSS, but code-oss is used everywhere in desktop data.

It should still be rebased automatically to the new app.

Yes, it's what I intended. Submit a new app with new ID, then mark this one as EOL and replace it with the new one via end-of-life-rebase.

[TingPing]

@TingPing I didn't notice MS using reverse-dns notation in VS Code OSS, but code-oss is used everywhere in desktop data.

In my opinion the app-id change is pointless then. Its not like we are matching upstream everything will still be renamed.

[gasinvein]

@TingPing It's still the easiest way to deal with existing user data, which, as I noted, might not be compatible. By chaining ID we don't touch existing installations at all and thus no chance to break it.

[TingPing]

Why would compatibility change?

[gasinvein]

Because it's built in a different way, probably contains slightly different npm packages, uses wrapper from the proprietary vscode flatpak, and is several major versions newer.

[TingPing]

"It updated" is going to happen no matter what, I'm not sure I understand the fear unless you experienced something broke compat.

[gasinvein]

@TingPing There are many internal bits and pieces that are different. I really don't want to dig into it to discover waht's different in resulting app and how exactly it can affect behavior. Maybe it's actually safe an nothing will break - but if not, who's going to fix it and how? Starting with clean data/config directories, on the other hand, is always-safe option.

[TingPing]

You are putting in the effort do whatever I suppose. It just seems like making a problem out of nothing to me.

[gasinvein]

No, I'm trying to avoid problems. If creating yet another repo under flathub org is a problem - well then, will submit the new build here. Arguing with you seems pointless anyway.

[TingPing]

Sorry if I came across as arguing, I was just confused about it.

[gasinvein]

Anyone interested - please give #56 a try and tell if everything works as expected.

[mzabaluev]

Chiming in to the discussion about the app id: it might be problematic in the long run to use the name prefix that is technically controlled by a different entity (it's borderline OK for com.visualstudio.code as long as it repacks the official binaries plus the supporting dependencies). I'm proposing a convention for cases like this in https://github.com/flathub/flathub/issues/1595.