Ability to install SDKs as Add-ons ?

[ghost]

Alot of apps on Flathub offer "Add-ons" which enhance/add extra functionality on top of another app. A notable example is OBS Studio (https://flathub.org/apps/com.obsproject.Studio)

Currently, to use any SDKs with VSCodium, the user needs to...

• Find out the version of the current runtime of VSCodium
• Manually install the desired SDK (of the same runtime version as VSCodium) from flathub/other sources
• Set an environment variable to make it accessible to VSCodium

(which i had to figure out the hard way when trying to use rust-analyzer, documented here: https://github.com/larina3315/personal-stuff/blob/main/coding/vsc-flatpak-rust.md#for-rust)

I am not aware of the current state of support for add-ons for flatpaks, but if this is something that can be done, it would be a massive QoL improvement and also be a improvement for new users.

[noonsleeper]

Hi @larina3315, currently we support the same add-ons or extensions made for vscode. You only need to install one like podman and will be available for codium. This is the same approach made by code-oss. Anyone can push an add-on on that namespace com.visualstudio.code.tool and make available for the three projects.

But I think the SDKs are really fast, up-to-date and also, well maintained, specially rust-stable and rust-nigthly. I use those two SDKs

flatpak install org.freedesktop.Sdk.Extension.rust-stable//23.08 -y
flatpak override --env=FLATPAK_ENABLE_SDK_EXT=rust-stable --user com.vscodium.codium
flatpak run com.vscodium.codium --install-extension rust-lang.rust-analyzer
flatpak run com.vscodium.codium --install-extension vadimcn.vscode-lldb

[ghost]

Hi @larina3315, currently we support the same add-ons or extensions made for vscode.

I think you misunderstood my request, I meant flatpak add-ons, not VSCode/VSCodium add-ons/extensions. My question was whether SDKs could be packaged/shown as flatpak add-ons, like pic below that shows different OBS Studio extensions.

[Dryadxon]

Anyone can push an add-on on that namespace com.visualstudio.code.tool and make available for the three projects.

~Maybe that's what @larina3315 is asking, add the namespace org.freedesktop.Sdk.Extension to the manifest so that package managers (e.g.: Gnome Software) show the SDKs as add-ons, for better discoverability?~ Unfortunately, that's not how things work.

...
add-extensions:
  com.visualstudio.code.tool:
  ...
  org.freedesktop.Sdk.Extension:
...

Correct me if I'm wrong 😅

[00pandora00]

Anyone can push an add-on on that namespace com.visualstudio.code.tool and make available for the three projects.

Maybe that's what @larina3315 is asking, add the namespace org.freedesktop.Sdk.Extension to the manifest so that package managers (e.g.: Gnome Software) show the SDKs as add-ons, for better discoverability?

...
add-extensions:
  com.visualstudio.code.tool:
  ...
  org.freedesktop.Sdk.Extension:
...

Correct me if I'm wrong 😅

that sound great!!! (even if it is not the proposal of the author of this issue). that will be a nice feature to have.

I spent about a week trying to get rust sdk to work (and now I have the same problem with lua). If this idea were implemented these kinds of problems would be reduced.

[noonsleeper]

I think you misunderstood my request, I meant flatpak add-ons, not VSCode/VSCodium add-ons/extensions. My question was whether SDKs could be packaged/shown as flatpak add-ons, like pic below that shows different OBS Studio extensions.

@larina3315, I understood what you say, and I think this is actually the best option, but we can find another options

currently we support the same add-ons or extensions made for vscode. You only need to install one like podman and will be available for codium. This is the same approach made by code-oss. Anyone can push an add-on on that namespace com.visualstudio.code.tool and make available for the three projects.

I know that there is a feature that obs and other projects are testing, but there is no documentation about it (If you found docs about plugins let me know).

But the main problem here is the big elephant in the room the maintainability of the SDK, currently I have no time or resources to maintain a set of plugins or tools, but I don't have any problems if someone wants to create and maintain the those. This problem is already resolved by the org.freedesktop.Sdk.Extension team, since they maintain an up-to-date version of the SDKs.

[noonsleeper]

Anyone can push an add-on on that namespace com.visualstudio.code.tool and make available for the three projects.

Maybe that's what @larina3315 is asking, add the namespace org.freedesktop.Sdk.Extension to the manifest so that package managers (e.g.: Gnome Software) show the SDKs as add-ons, for better discoverability?

...
add-extensions:
  com.visualstudio.code.tool:
  ...
  org.freedesktop.Sdk.Extension:
...

Correct me if I'm wrong 😅

Hi @Dryadxon, sadly doesn't work, at least on my tests, but maybe someone can find a solution using this. That could be awesome!

[Dryadxon]

Hi @Dryadxon, sadly doesn't work

Unfortunately that's true, only packages published as Add-ons can appear in that section. But there are only a few SDKs that can do this because most are published as runtimes. And even those who can, have to include an extends tag in their manifest.xml for every IDE and editor published on Flathub, which puts a lot of burden on maintainers. I was hoping it would be simpler than that 😅

[noonsleeper]

I was hoping it would be simpler than that 😅

Me too @Dryadxon, also thanks for the docs!

[ghost]

Anyone can push an add-on on that namespace com.visualstudio.code.tool and make available for the three projects.

Maybe that's what @larina3315 is asking, add the namespace org.freedesktop.Sdk.Extension to the manifest so that package managers (e.g.: Gnome Software) show the SDKs as add-ons, for better discoverability?

...
add-extensions:
  com.visualstudio.code.tool:
  ...
  org.freedesktop.Sdk.Extension:
...

Correct me if I'm wrong 😅

yes this is precisely what i was asking for

[00pandora00]

Hi @Dryadxon, sadly doesn't work

Unfortunately that's true, only packages published as Add-ons can appear in that section. But there are only a few SDKs that can do this because most are published as runtimes. And even those who can, have to include an extends tag in their manifest.xml for every IDE and editor published on Flathub, which puts a lot of burden on maintainers. I was hoping it would be simpler than that 😅

no is possible to add runtimes the same way you add addons? if not, this just need to be requested to the flatpak team, right?

[Dryadxon]

no is possible to add runtimes the same way you add addons?

The AppStream specification says that only components of the type addon can have extends tags. Package managers use these tags to list extensions in the Add-on tab of each application's page.

if not, this just need to be requested to the flatpak team, right?

Of course, we can request it. But I don't think the Add-ons tab is the best place at this point. It would be better to ask for a separate section to list the SDKs, and on the page of each development app, add a reference to that new section.

[Dryadxon]

I think it is clear that this package cannot do anything about this request. And I would suggest to close the issue.

[00pandora00]

Of course, we can request it. But I don't think the Add-ons tab is the best place at this point. It would be better to ask for a separate section to list the SDKs, and on the page of each development app, add a reference to that new section.

so... instead of having one list for addons, will we have two lists? (one for SDKs and one for addons). if that is the case i agree, that is better.

I think it is clear that this package cannot do anything about this request. And I would suggest to close the issue.

yes, this package for the moment can't help. but i don't recommend closing this issue for various reasons:

1. will confuse people to think this issue is fix.
2. if the "issue" is resolve we need at issue page to inform to this package, so they can fix it in here as well.
3. we can put the link of the "request" here. with that, people can go to the link and help.

[noonsleeper]

1. will confuse people to think this issue is fix.

for this there is the label wontfix

• if the "issue" is resolve we need at issue page to inform to this package, so they can fix it in here as well.

• we can put the link of the "request" here. with that, people can go to the link and help.

and for these, there is any problem about close this and open a new issue when the feature will be ready.

[00pandora00]

1. will confuse people to think this issue is fix.

for this there is the label wontfix

• if the "issue" is resolve we need at issue page to inform to this package, so they can fix it in here as well.
• we can put the link of the "request" here. with that, people can go to the link and help.

and for these, there is any problem about close this and open a new issue when the feature will be ready.

OK, so I guess it's okay to close this issue.

note 1: before closing this issue, it would be good to wait for its author in case he has something else to say. note 2: who will make the new report? (the one for the SDK lists for flatpak on flapak discussions ) (if no one offers, I can do it)

[ghost]

note 1: before closing this issue, it would be good to wait for its author in case he has something else to say.

looks like either very poor documentation or unimplemented feature on flatpak's side, so ig it's logical to close the issue as there's nothing to be done on the VSCodium packaging side.

[00pandora00]

note 1: before closing this issue, it would be good to wait for its author in case he has something else to say.

looks like either very poor documentation or unimplemented feature on flatpak's side, so ig it's logical to close the issue as there's nothing to be done on the VSCodium packaging side.

ok. i post a request in "flatpak discussions". if someone want to help/comment on this issue pls do it there.

https://discourse.flathub.org/t/support-for-list-of-sdks-similar-to-list-for-addons/5702

and in flatpak repo: https://github.com/flatpak/flatpak/issues/5621