flathub
flathub copied to clipboard
flathub
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
Most of the IDEs and code editors on flathub including VS Code seem to be limited in ways that uninformed users seem likely to interpret as broken (uninformed as in, devs with advanced linux knowledge but limited or no flathub/flatpak knowledge).
I spent many days testing a huge selection of them and the vast majority suffer from one or all of the following problems: 1. more niche language servers don't work even if the plugin for them is installed, 2. often no language servers work even for mainstream languages, 3. if they have a build project button it will in the vast majority of cases not work on your project even if it uses just standard tooling like "npm" or "cmake", 4. if the build button works for standard tooling it won't as soon as you use a slightly more unusual library because of e.g. missing headers with obscure error messages rather than any pointers on how to install them, 5. if they have an integrated terminal usually you won't be able to build from there either when it usually would work, 6. debugging also often won't work even with the plugins for it installed, 7. if you want to use a custom language server (like e.g. kate and some other editors allow to specify without a plugin) it won't work either even if you installed it via the usual ways on your system.
Basically, beyond basic text editing and syntax highlighting, most of the functionality seems to be broken. The problem seems to be that even if headers and/or language servers, build tooling, etc. are installed and even if the flatpak has full filesystem access, due to the wrong $PATH env and defaulting to /usr inside and such, the IDE won't see it. I suggested as a solution to this that when the host and IDE app both use glibc, and the IDE flathub packager is confident the packaged app is portable, that it can be run with most access redirected to the outside env and filesystem: https://github.com/flatpak/flatpak/issues/5644 But it was rejected as out of scope for flatpak.
That seems fair enough @ rejection, but then I guess the question is does it even make sense to have all the broken IDEs and code editors on flathub? I see constant issues filed, and I filed some on my own before realizing what is going on, before people catch on to this issue of those who just wanted to get & use an IDE from flathub, so this doesn't seem to be intuitive or expected for most people. There seems to be no alternative place like flathub for linux software distribution on such a wide scale though, especially not one integrated into KDE Discover and GNOME Software, so I guess the question is what else could fill the gap?
I find the current situation a little sad and therefore wanted to suggest that maybe it could be useful to figure out how it could be improved at least in the long term.
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.
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
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.
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.
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.
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
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.
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).
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
The current set of IDEs published on Flatpak work for a lot of people as the download numbers indicate.
If there are specific issues around a particular application, it should be reported to them and the maintainer/developers of it should figure out what's needed to fix it if they want to have feature parity between flatpak and non-flatpak variants.
They can also put a note in the metainfo description tag, have a dialogue spawn on first start to let the user know about the limitations. (VS code flatpak already does it)
There isn't a scope for fundamental changes that you're hoping for given how flatpak and the current system works.
I'll close this as this doesn't seem very actionable.
For what it's worth, I downloaded about 5-10 IDEs just to test them out and then ended up abandoning them due to these issues. I haven't encountered any IDE that spawns such a dialogue so far, just without exception silently failing ones. (E.g. VS Codium doesn't have such a dialogue last time I checked.) So the download numbers might be misleading if you don't have any actual usage info, which I assume for privacy reasons isn't collected.
Vscode does spawn a dialogue on the first install which comes from here https://github.com/flathub-infra/ide-flatpak-wrapper/blob/master/first_run.txt Nothing stops any other IDEs from implementing similar solutions as a warning/information.
Applications don't generally spawn dialogues for missing dependencies other than printing line in the terminal and none of these were written with flatpak in mind. So they can't really tell you in the form of dialogues what to install when certain errors occurs.
I don't know if it's just me, but that README doesn't actually look too useful to me. How do you install any dev tooling outside of standardized prepackaged toolsets? With standardized ones in my experience you often run into a wall of things missing really quickly, e.g. what if you just want some additional headers that you would usually install via apt? It doesn't mention apt. It doesn't mention if wget or curl is available either, or how or if changes to the sandbox file system are persisted or which folder that would be. I can't imagine any non-beginner dev working with this and not running into all of these questions fairly quickly, which is I think part of the problem.
Apart from that I filed this issue not because IDEs could solve this situation, but because close to none seem to actually do so and that seems like a problem.
I just pondered this some more, maybe this dialog could be expanded into an actual small program that any IDE could be encouraged to include which can be run at launch? The program could provide this help text, but then some actual buttons or input fields or whatever to offer downloading some repository package, and/or to open and show a folder inside the sandbox where portable binary tools could be put for $PATH access inside without flatpak spawn (which will often be required for addons/extensions to properly pick them up I imagine), and other such things. Then any IDE could just launch this thing along with itself, and maybe that would encourage any such solutions spreading more across the packages.
As another option, I think an app image like mode could still be an even better solution for IDEs that can be packaged like that. This would for example likely be very feasible for any IDE written in Go, or some other language that has a ffocus on portable binaries more than many traditional languages. This could work e.g. by white listing the files from a flatpak image that the app needs, which would then via some sort of filesystem overlay be overlayed with the host file system, with any writes and reads outside of these paths going to the host. I assume this is possible somehow, given what I've seen docker map around.
Edit/addendum: I get there's maybe no time to implement any of this, that's fine and I apologize for suggesting stuff that would take up time. But hopefully if there's at least some idea what the solution could be, that could help with it becoming reality at some point.
I guess instead of a program that is also started with the ide, it would be nicer to just have an ide assistant - that works similar to flatseal and helps you manage these kind of things. Then ide's could mention that tooling. @ell1e would you be able to write something like that?