Make FLATPAK_ENABLE_SDK_EXT=* the default

[Job79]

Hello!

Most users are probably going to add FLATPAK_ENABLE_SDK_EXT=* anyways, so why not make it the default? Makes installing the IDE just a little bit easier. Also prevents users from forgetting to do this and getting stuck (which happened to me at first)

It would still be possible to override this setting, so users that have multiple versions of a SDK installed will still be able to specify certain versions. And I think these users are greatly the minority, so this default would probably make more sense.

What do you think? Are there any downsides to this that I am overlooking?

[x80486]

Assumptions aside, this is an opt-in choice.

I may be wrong, but using this is like installing SDKs in your operating system, one at a time. Consequently, when you install IDEA (through other means) it doesn't bring all the SDKs and "activates" them — which is what FLATPAK_ENABLE_SDK_EXT does after you install a given SDK.

Moreover, I would have to check how would that work if you happen to have different versions from the same SDK :thinking:

In practice, I think once you have several projects using different versions from a given SDK, these extensions are pretty useless, unless you run IDEA using the ones you would like to use for that particular application — e.g.: --env=FLATPAK_ENABLE_SDK_EXT=node18. Nevertheless, that wouldn't let you change to another project that uses a different one — in version or type. Additionally, you will have to synchronize that with your host. That's why I never use these — too mane moving parts.

It's easier to install what you need in the host and use it across the board.

[Job79]

Assumptions aside, this is an opt-in choice.

To me it seems like a better default because I don't really see it causing problems for users and it makes installing extension SDKs easier. But if it somehow could cause problems, I am wrong and this shouldn't be the default.

I may be wrong, but using this is like installing SDKs in your operating system, one at a time. Consequently, when you install IDEA (through other means) it doesn't bring all the SDKs and "activates" them — which is what FLATPAK_ENABLE_SDK_EXT does after you install a given SDK.

I see it more like adding things automatically to the PATH when you install them. It only activates the SDKs that you have installed and the only thing it really does is adding things to the PATH as far as I know. Please correct me if I am wrong here.

So the code that activates when setting FLATPAK_ENABLE_SDK_EXT to * is located here. It basically sources all files of the installed SDKs. When printing the content of these files for my locally installed extension SDKs I get the following:

#!/bin/sh
export GOROOT=/usr/lib/sdk/golang
export PATH=$PATH:$GOROOT/bin
#!/bin/sh
export PATH=$PATH:/usr/lib/sdk/node18/bin
export npm_config_nodedir=/usr/lib/sdk/node18
#!/bin/sh
export JAVA_HOME=/usr/lib/sdk/openjdk/jvm/openjdk-21
export PATH=$PATH:/usr/lib/sdk/openjdk/bin
#!/bin/sh
export PATH=$PATH:/usr/lib/sdk/php82/bin:/var/config/composer/vendor/bin

So it seems like the only thing it is doing is adding installed extension SDKs to the PATH, which also automatically happens when installing things on the host.

Moreover, I would have to check how would that work if you happen to have different versions from the same SDK 🤔

In practice, I think once you have several projects using different versions from a given SDK, these extensions are pretty useless, unless you run IDEA using the ones you would like to use for that particular application — e.g.: --env=FLATPAK_ENABLE_SDK_EXT=node18. Nevertheless, that wouldn't let you change to another project that uses a different one — in version or type. Additionally, you will have to synchronize that with your host. That's why I never use these — too mane moving parts.

Using multiple versions like that seems pretty difficult 😄. I don't know what would happen when installing multiple versions, and can't really test it because older versions don't support the freedesktop 23 SDK.

It's easier to install what you need in the host and use it across the board.

When I tried that it didn't work. Do you point the IDE to the binary on the host? Does intellisense work?

[x80486]

What I meant with multiple versions is that you can have org.freedesktop.Sdk.Extension.openjdk17, org.freedesktop.Sdk.Extension.openjdk21, etc. ...and if you activate all those, it may not create the desired result. I would assume it should go by the order in which they are discovered :monocle_face:

When I tried that it didn't work. Do you point the IDE to the binary on the host? Does intellisense work?

Probably because the sdks/tools were installed using the operating system's package manager. That wouldn't work and it's not realistic as well, because once you have several projects they are going to be in different versions of Go, Java, you name it. Take a look at the excellent RTX: https://github.com/jdx/rtx

It will install and manage all the tools in your $HOME. In practice, you would need something like this, regardless — there are plenty of similar tools.

If you still want to pursue the FLATPAK_ENABLE_SDK_EXT you can test it and let me know, otherwise, as soon as I have some time I'll give it a whirl to see how that works with different use cases and settings.

[Job79]

What I meant with multiple versions is that you can have org.freedesktop.Sdk.Extension.openjdk17, org.freedesktop.Sdk.Extension.openjdk21, etc. ...and if you activate all those, it may not create the desired result. I would assume it should go by the order in which they are discovered 🧐

Nodejs and php didn't have builds for the older versions against the freedesktop 23 sdk but java indeed does. Just checked and it seems to take a random version. It adds all of them to the PATH so it uses the first one that it encounters. But not really sure if this is a problem? Installing all of them on the host results in the same problem if I remember correctly?

Probably because the sdks/tools were installed using the operating system's package manager. That wouldn't work and it's not realistic as well, because once you have several projects they are going to be in different versions of Go, Java, you name it. Take a look at the excellent RTX: https://github.com/jdx/rtx

That sounds great! Didn't know such projects existed. Will try to use it for my workflow and see how it goes. It looks like a really good match for silverblue and flatpak.

Using it in the terminal is pretty straightforward, but how do I specify to the IDE that it needs to use the installed executable for intellisense? Is there an easy way to do this that I am overlooking?

[x80486]

Nodejs and php didn't have builds for the older versions against the freedesktop 23 sdk but java indeed does. Just checked and it seems to take a random version. It adds all of them to the PATH so it uses the first one that it encounters. But not really sure if this is a problem? Installing all of them on the host results in the same problem if I remember correctly?

It would be the same for the host, with the caveat that the user will set the JAVA_HOME variable manually, rather than a system.

That sounds great! Didn't know such projects existed. Will try to use it for my workflow and see how it goes. It looks like a really good match for silverblue and flatpak.

It really is a must. It wouldn't when you are starting, but there will be a time where you will need different version of a given SDK, and at that point "juggling" with the system installs is not an option.

Using it in the terminal is pretty straightforward, but how do I specify to the IDE that it needs to use the installed executable for intellisense? Is there an easy way to do this that I am overlooking?

In the IDE you just need to specify the path to the given SDK, be it Java, Go, Node.js, etc:

[Job79]

It would be the same for the host, with the caveat that the user will set the JAVA_HOME variable manually, rather than a system.

That makes sense. FLATPAK_ENABLE_SDK_EXT=* should probably not be the default then. Thanks for sharing rtx with me, learned a lot from this issue! I will close this issue now because you changed my mind.