Most of the dev tooling on flathub seems to be limited such that an uninformed user might perceive it as broken, and it doesn't really look like this will be fixed any time soon about flathub

[TingPing]

I think you just want a different service than Flathub.

[ell1e]

Ah, cool! I assume most issues could be fixed like that on an individual user level. But it can be so opaque to even figure out what the problem is that as a user it can be quite frustrating, and I would assume many just walk away instead.

[HugLifeTiZ]

I see this topic come up a lot, and I think that the real cure to this ailment is a more fundamental change in how we approach development.

It's a tale as old as Flatpak has existed: "I installed my development tooling with my distro's package manager, and the Flatpak of my IDE can't use it!" So folks look for ways to hack the sandbox apart or otherwise escape the sandbox so that the IDE can get to the tooling. But it seems like folks don't even think to ask this question: Why'd you put the tooling there to begin with? Was it a conscious decision to use your system's package manager, or did you just follow instructions and/or convention, not having bothered to think of any other way?

Think about it: your entire development setup is fraught if it is dependent upon your system's package manager. If a distro upgrade goes bad, your development setup is hosed. If you have to reinstall your distro, or change your distro, you have to reinstall everything all over again. And development sometimes requires a lot of special tooling; given that, my system package manager is the last place I would want to put any development tools.

The point of development tools is usually not to have particular integration with the host system. It's to compile code that probably lives somehwere in $HOME, and to provide services to an IDE for working with that code. We should be approaching this the other way: by encouraging the installation of tooling in a way that is independent of the base system--both by dependency and by location--so that it can be safely used in any distro, be that your base distro, or the overlay distro that is one of the Flatpak runtimes. Runtime/version managers like ASDF are a potential good way to start, because they centralize installation of tooling to a specific location that is safe to expose to the sandbox, and most of the plugins rely on distro-agnostic binaries. Another good way may be relying on containers like toolbox, but Flatpak may need special capabilities for reaching from one container into another. SDK extensions are probably good, too.

But I strongly believe that insistence that IDEs and development tools should be able to use host system tooling is backwards. It's more forward thinking to keep tooling away from the host system.

[TingPing]

It helps to be very clear with wording. These tools are not "broken" they are "limited" by the sandbox.

You can do everything from vscode including compiling software, running language servers, etc. Just they run in the sandbox and not on the host. This is a severe limitation but does not remove all usefulness.

[TingPing]

Some packages including vscode include a note about this: https://github.com/flathub/com.visualstudio.code/blob/master/com.visualstudio.code.metainfo.xml

IMPORTANT: To use certain features in this flatpacked version (like the integrated terminal), please see https://github.com/flathub/com.visualstudio.code#readme

[ell1e]

My reasoning why I think that word isn't entirely out there: in the sense that you go through their usual UI to say "install the python support, please" (or it already says it's installed) and then basic auto completion and such just doesn't work. That it doesn't work to such a level is kind of rare, but happens too. For the stuff that only works weirdly like the terminal you're referencing, usually there will also be zero UI elements or warnings of any kind and instead just weird unexplained errors, which I personally also think most people would consider broken as a first impression at least. But maybe I'm wrong.

I don't mean to be mean for the sake of it, it's just how it came across to me as a user of these pieces of software, and from comments on issues it seemed to me like I'm not the only one.

[TingPing]

I would expect Python support to work out of the box, its in the runtime, it can install dependencies locally, etc.

Until you hit a system dependency for a C library or something.

[ell1e]

Until you hit a system dependency for a C library or something.

But which non-trivial project doesn't? And I've seen Python not even work, or work but any install deps fail, and other things. (E.g. for VS Code, npm just isn't there. How do you even install npm then? Who knows, the IDE doesn't tell you.)

I mean we can debate how big this issue is but I think it's fair to acknowledge that even if not everyone, then a lot of people especially those coding not just occasionally will hit these limitations and end up with a bad impression and think that IDEs on flatpak simply aren't worth even trying anymore. I'm kind of even in that camp still, even that I now know somewhat the reasons behind the scenes. And I just find it a little regrettable and wondered if there isn't any way to address that which would actually make its way into most IDEs without much trouble, unlike flatpak's host spawn.

[TingPing]

for VS Code, npm just isn't there. How do you even install npm then?

I know it isn't obvious but it is possible: https://github.com/flathub/org.freedesktop.Sdk.Extension.node18

[ell1e]

Maybe a constructive idea: maybe some way could be found to extend flathub to also offer AppImages, and then for GNOME Software and KDE Discover to support that too. Then things that don't quite work right inside flatpak could be offered as AppImages instead, especially in situations where a sandbox might be seen as more of a downside (which would likely apply to IDEs at least for many of the users).

[ell1e]

Flathub is currently likely seen by many users, and GNOME Software/KDE Discover for sure have to be seen like that, as the one unified place where "everything that my distro doesn't have or only has outdated" is. So I think it makes sense to ponder if this use case can't fit in there better, given the affected category of software seems pretty significant. It wouldn't help anyone if somebody makes a separate thing to KDE Discover, GNOME Discover, and flathub.org, puts everything up separately, and now everyone has to browse two things and possibly even figure out that on one thing (flathub) the versions are limited in often undesired ways, etc. Or how would that be desirable?

So I think it makes sense to bring this up here.

[razzeee]

Gnome Software implements plugins, so it can consume package streams from whatever has a plugin implemented, I would assume the same for KDE Discover.

Having to communicate to users, that stuff is sandboxed unless you install that app would be a nightmare IMO. We're trying to move the ecosystem towards portals, not away from them.

I think the most productive thing that could be done, is explore the stuff that breaks and how to unbreak it, then document that. Like how to install npm from above, but in an easy to find website. But I don't think that should be part of flathub.

[ell1e]

Having to communicate to users, that stuff is sandboxed unless you install that app would be a nightmare IMO.

I don't get quite that remark, that already seems to be how it's like today (for host filesystem access apps) and it seems to work and to be communicated perfectly fine.

[ell1e]

I mean to have it isolated would be fine if the IDE flatpaks usually offered another obvious way to install the needed tools and dependencies inside. But I haven't even seen one single IDE ever do that (edit: I mean in a way where the user is actively prompted in some obvious way and it's not like some arcane research project to find out how). Until that is the case, I fail to see how IDE tooling on flatpak makes any sense with the experience it usually has, and that doesn't really seem to be changing, which was my point.

So in theory I agree with your point, but in practice it just doesn't seem to work out.

Edit 2: removed irrelevant arguments

[razzeee]

Builder is doing that I guess

[ell1e]

Builder seems to instead make the host tooling available in the terminal by tearing down the sandboxing with e.g. copying over many env vars, from what I understand, which is actually what I suggested in another ticket to move into flatpak as a generalized solution. But since that was also rejected, hence I suggested that maybe IDEs in their current shape or form don't make too much sense on flatpak/flathub.

[TingPing]

It wasn't "rejected" it is impossible.

Builder very specifically understands the context of projects and where commands must run. It is a detailed task that the IDE must do itself.

Flatpak gives you the ability to run commands on the host, which Builder uses, and this is about the best it can do.

[ell1e]

I apologize for misrepresenting that. The conclusion however seems to be the same, that making such a split environment work well enough for the user seems not to be working out for most IDEs.

[TingPing]

Because most IDEs have never tried. This is a design that some IDEs do support, like VSCode, somebody just needs to put in the work.

[ell1e]

I'm repeating myself at this point, but I think it seems likely at this point this won't happen. My apologies, I'll try to be productive now and move on.