Nineteen distribution channels later: what it actually costs to give a terminal editor away for free on Linux, and why the next step is a static musl binary that updates itself.
It is equivalent until Flatpak adds a new (probably completely justified) limitation to its sandbox that breaks your (needs unrestricted system-wide permissions) application, sure. Nevermind if you decide to add more features that go beyond what the sandbox allows, and then you need to figure out why they’re broken in your flatpak and what new flags you need to unbreak them. The problem is you’re constantly swimming upstream against a very strong current. It’s not a very sustainable mode of development. Like OP said, flatpak is designed for sandboxed desktop GUIs. It may be convenient at first to shoehorn your TUI application into it, but you’re working against its design and intent, and that is a genuine problem, for many reasons.
npm -g is another TUI install method I loathe. pipx/uv shares most of the same issues. Like the author, I’ve gone through almost all of the same options they have, and come to basically the same conclusions. There really is no good option for packaging and managing userspace TUI utilities. And it’s brutal. I hate that so many terminal utilities have standardized to use completely unrestricted, opaque and dangerous curl/sh copy-pastes, leaving anyone who’s not both fluent in shell script and willing to invest the time to inspect what the scripts are doing out in the cold, bravely running commands that are potentially malicious with no safety net. I understand it, it’s viable, it works, I do it myself for my own projects, but we have to acknowledge that it’s a symptom of the lack of any better solution for TUI packaging, and it’s okay to admit that it sucks, and we could do something so much better.
It is equivalent until Flatpak adds a new (probably completely justified) limitation to its sandbox that breaks your (needs unrestricted system-wide permissions) application, sure. Nevermind if you decide to add more features that go beyond what the sandbox allows, and then you need to figure out why they’re broken in your flatpak and what new flags you need to unbreak them. The problem is you’re constantly swimming upstream against a very strong current. It’s not a very sustainable mode of development. Like OP said, flatpak is designed for sandboxed desktop GUIs. It may be convenient at first to shoehorn your TUI application into it, but you’re working against its design and intent, and that is a genuine problem, for many reasons.
npm -gis another TUI install method I loathe. pipx/uv shares most of the same issues. Like the author, I’ve gone through almost all of the same options they have, and come to basically the same conclusions. There really is no good option for packaging and managing userspace TUI utilities. And it’s brutal. I hate that so many terminal utilities have standardized to use completely unrestricted, opaque and dangerous curl/sh copy-pastes, leaving anyone who’s not both fluent in shell script and willing to invest the time to inspect what the scripts are doing out in the cold, bravely running commands that are potentially malicious with no safety net. I understand it, it’s viable, it works, I do it myself for my own projects, but we have to acknowledge that it’s a symptom of the lack of any better solution for TUI packaging, and it’s okay to admit that it sucks, and we could do something so much better.