I love Flatpaks, the programs are nicely separated so they don’t interfere with each other. They also don’t have flaws like Snap’s low performance or Nix’s complexity.

But being limited to only graphical apps seems like a real drawback. If one wants to use Flatpaks as their primary package manager there have to be some awkward workarounds for cli programs.

E.g., the prime Flatpak experiene is supposed to be on immutable distros like Silverblue. But to install regular cli programs you are expected to spin up a distrobox (or toolbox) and install those programs there.

Having one arch distrobox where I get my cli programs from will not work, as the package entropy over time will get me the very dependency issues that Flatpak wants to solve.

So what is the solution here? Have multiple distroboxes and install packages in those in alternation and hope the boxes don’t break? Use Nix alongside Flatpak? Use Snaps?

  • Max-P@lemmy.max-p.me
    431·
    10 months ago

    Flatpak can do CLI apps it’s just mildly unwieldy because of the whole flatpak run ....

    If you want reproducible dev environments, yeah you’re pushed to container solutions be it distrobox, Podman or Docker. Or something like nix as a user.

    If you install a Debian distrobox it’ll be as reliable as Debian itself is. It’s only an issue when you’re after 100% reproducible systems, which Docker can help somewhat with, or again, nix. Or NixOS if you really want it all system-wide.

    • atzanteol@sh.itjust.works
      185·
      10 months ago

      flatpak run org.gimp.Gimp image.png vs. gimp image.png or even xdg-open image.png. “Mildly unwieldy” I suppose but a massive pain in the ass in practice. I can’t believe they thought that it was a good idea to require all that and provide no way to create a script in /usr/local/bin or even .local/bin.

        • atzanteol@sh.itjust.works
          398·
          10 months ago

          Oh my God I never thought of that! /s

          What a pain in the ass to require me to maintain a set of aliases for everything I install. Great user experience.

      • Skull giver@popplesburger.hilciferous.nl
        4·
        10 months ago

        All you need is to put

        #!/usr/bin/bash
flatpak run org.gimp.Gimp $*

        in .local/bin/gimp or /usr/local/bin and you can just call gimp image.png. A basic alias in your bashrc works, too.

        • atzanteol@sh.itjust.works
          187·
          10 months ago

          That’s a pain in the ass. Why not automate it with the install? They already create .desktop files FFS.

              • Skull giver@popplesburger.hilciferous.nl
                4·
                10 months ago

                It did for me, but I broke it somehow (I really need to reinstall my desktop). According to the Arch docs, the exports directory is added to /etc/profile

                As for why it’s not done upstream, this seems to be the thread where Flatpak’s considerations were mentioned: https://github.com/flatpak/flatpak/issues/3573

                I don’t want to auto-add the wrapper dirs to the real PATH, because such a modification is bound to break a lot of users setups.

                I don’t necessarily agree with them, but it should answer the “why” question.

                • AProfessional@lemmy.worldEnglish
                  1·
                  10 months ago

                  They are only aliases too. People will be disappointed if they expect it to behave like the unsandboxed command.

            • atzanteol@sh.itjust.works
              42·
              10 months ago

              Really? That’s a thing? I don’t mind a one-time PATH modification and was excited to see this but… I don’t see that path on my system. Maybe it’s optional and none of my applications are using it?

              I also don’t see any mention of that in the flatpak.org setup steps. And almost nobody replying here even knows about it. And all of the examples of running a flatpak from the CLI on flatpak.org and flathub.org use the flatpak run org.gimp.Gimp version.

              So it seems like it’s a feature, but it’s poorly documented, poorly advertised, and not used… :-(

              Edit: So I did find that directory on another system of mine. No idea why it’s there on one and not the other. Maybe a version thing. And gimp is symlinked as “org.gimp.Gimp”. What a failure… 🤦

      • Thann@lemmy.mlEnglish
        3·
        10 months ago

        Flatpak should export mimetypes so xdg-open should work if there isn’t another handler registered

  • j0rge@lemmy.ml
    201·
    10 months ago

    the package entropy over time will get me the very dependency issues that Flatpak wants to solve.

    You can declare your distroboxes so that they get created regularly from scratch instead of upgrading in place: https://github.com/89luca89/distrobox/blob/main/docs/usage/distrobox-assemble.md

    That way the entropy never hits you. Then use the Prompt terminal https://gitlab.gnome.org/chergert/prompt to make it just part of your terminal ootb.

  • sweet@lemmy.ml
    202·
    10 months ago

    I wrote a nice little CLI tool that lets you browse the flatpak store in the terminal and has an option to link all your flatpaks to their short names. Its really just a wrapper bash script that runs flatpak, but I like it because it goes from com.Blender.Blender to just “blender” and it works on the command line.

  • Dehydrated@lemmy.world
    202·
    10 months ago

    I think Nix is great for installing CLI apps, it’s not that complicated, in fact, it can make many things in your life easier.

    • d3Xt3r@lemmy.nzM
      7·
      10 months ago

      This.

      Also, @Libretto@iusearchlinux.fyi - you not be aware but you can use Nix in an imperative way (as opposed to declarative), which doesn’t require learning the Nix language or editing config files etc.

      Eg: say you wanted to install tealdeer, all you need to do is run: nix profile install nixpkgs#tealdeer

      There are similar one-liners to search, upgrade, rollback etc.

      I use Fedora uBlue (Bazzite), and use Nix to install all my CLI apps, and Flatpak for all my GUI apps. Been running this setup for a few months on and it’s been great experience (bit of a learning curve doing this way of course, but I’m pretty happy with my setup now).

      • Libretto@iusearchlinux.fyiOP
        3·
        10 months ago

        Thanks, I will try that out. I want to use uBlue as well, but cli program installation has been holding me back.

        uBlue also makes nix available via fleek, but the way you describe it it seems easier to just use nix directly

        • d3Xt3r@lemmy.nzM
          3·
          10 months ago

          Yep exactly. I tried Fleek first, but it just added a whole bunch of layers of complexity which I wasn’t prepared to get into. In fact, the first time I tried setting it up, I couldn’t even get it to work with a basic preset (“bling” level), because some dependency in the chain somewhere was broken and it thru a bunch of errors… and that to me wasn’t a good sign of things to come, so I abandoned the idea.

          Nix however has been super easy to use, literally just install/uninstall stuff just like how you’d use a regular package manager, except it installs to your user profile/path, doesn’t need sudo, no container/sandbox slowing things down, no Distrobox limitations and bugs, and most impressively it’s fast. Like so fast that stuff installs instantly, and you’d think that the command didn’t work!

        • j0rge@lemmy.ml
          2·
          10 months ago

          ublue contributor here. We’re set up so you can install any cli program from any distro transparently. Should we outline that more in our docs?

          • Libretto@iusearchlinux.fyiOP
            1·
            10 months ago

            hey, I’m a bit overwhelmed by all the options you provide to install cli programs. There’s nix, fleek, devbox, devcontainers, distrobox, incus, brew and probably even more options.

            I just want one preferred way to install my cli programs globally, like on normal distributions, but it is not clear which option is the default one. After digging through posts on the forum I found out that the ubuntu distrobox with apt is supposed to be this default installation environment. Maybe make that clear when someone opens the host terminal on bluefin, or let the bluefin installer give this info to the user.

            Even then, projectbluefin.io in the FAQ section suggests that homebrew is the creator’s preferred installation method, not ubuntu. So which one should I use now? On one hand, bluefin’s default DE is GNOME which is very simplified and has one correct workflow, on the other hand bluefin provides a multitude of choices all seeming equally viable, which is more in line with KDE’s philosophy.

            Also, why prefer homebrew over something like nix? AFAIK, homebrew leads to the same dependency issues that the traditional package managers have.

            Additionally, what is making ublue hard for me is that all the important info seems to be scattered on the ublue website, blog posts and forum posts. I’d really like it if there would be one website which gives clear guidance for people who are new to bluefin (or bazzite etc.). Not explaining all of the possibilites, but just the most important stuff to get started. Just a really dumbed down, compressed version of the existing ublue guides. The users can figure out more themselves afterwards.

            Something like:

            • install bluefin-dx (not the regular bluefin)
            • only install graphical stuff via flatpak
            • only use the ubuntu terminal for any terminal stuff, including cli program installation
            • do not use the host terminal unless you are doing host administration with ujust or rpm-ostree
            • etc.

            These starter instructions may not be perfect, but at least then the users have a daily driver they can learn more about over time instead of having to learn everything before daily-driving ublue.

            Thank you for all the hard work you guys are putting into this, I’m excited to see the project mature

            • j0rge@lemmy.ml
              1·
              10 months ago

              Maybe make that clear when someone opens the host terminal on bluefin, or let the bluefin installer give this info to the user.

              We’re working on a dynamic motd system that will give you some guidance when you first run the terminal. Here’s the issue if you have some feedback! https://github.com/ublue-os/bluefin/issues/609

              So which one should I use now?

              Yeah the reason it’s ubuntu by default is that’s what the target audience uses, but we’ve been working on a wolfi/brew distrobox that ends up being a better experience, so we’re mulling shipping that by default.

              Also, why prefer homebrew over something like nix? AFAIK, homebrew leads to the same dependency issues that the traditional package managers have.

              We picked homebrew because it’s overwhelmingly the most popular package manager for cloud people and has everything people need. nix doesn’t really fit in a container world, but we don’t stop people from using it, and with devbox there’s at least a common devcontainer pattern people can use. I haven’t really run into dependency issues with homebrew but the new bluefin-cli container maintains state and is destroyed/rebuilt regularly so that hopefully won’t be a problem.

              scattered on the ublue website, blog posts and forum posts.

              Yeah this is annoying and we’re in the middle of consolidating docs, I’m hoping to streamline it by Fedora 40. I’m also working on a 10m “how to use this thing” video, it’s just been hard to spend time on it when we’re still making it. We’re almost feature complete at this point so I’ll start on this soon.

              Your starter steps are exactly what we want the default to be, do you think we should say that more strongly? Thanks for your feedback! I think we can clean up a bunch of this stuff to make it easier.

              • Libretto@iusearchlinux.fyiOP
                1·
                10 months ago

                Thank you for the answers and listening to the feedback.

                Your starter steps are exactly what we want the default to be, do you think we should say that more strongly?

                Yes, I’d definitely try to make it more clear to the user that the ubuntu/wolfi distrobox is the way to go and that all the other installation methods are just bonus for those who need it.

                Also, I think it’s a bit confusing for newcomers whether to choose bluefin or -dx. It seems like dx is always the better option, even if you end up not using all of the extra features

  • heartsofwar@lemmy.world
    122·
    10 months ago

    Hmm… this is a little bit of a misunderstanding.

    Flatpak is not just for graphical apps. As others have mentioned, you can run non-graphical apps from the CLI via the flatpak run ... command and even create aliases to avoid typing all of it out.

    The misunderstanding is that Flatpak has a hard requirement that a “graphical” or Desktop environment must be installed (snap does not). In other words, Flatpak is not currently suitable for a headless server environment whereas snaps are. This is something the RH devs have acknowledged as being something they want to focus on in the future once the industry chooses a standard: Flatpak, Snap, AppImage, etc

    • Libretto@iusearchlinux.fyiOP
      5·
      10 months ago

      The point is that you can not find most cli programs on Flathub, de facto making Flatpaks unsuitable for cli programs. Snapcraft on the other hand hosts neofetch, dust, youtube-dl etc.

      • heartsofwar@lemmy.world
        21·
        10 months ago

        The point is that you can not find most cli programs on Flathub, de facto making Flatpaks unsuitable for cli programs

        not really; The lack of finding CLI programs on Flathub is more of an indication that the developers of CLI / TUI programs don’t think it is beneficial to adopt Flatpak at this time for whatever reason.

        Keep in mind that among several things, Flatpak is meant to put the labor of package maintenance back into the hands of the software developers. For 30+ years the distro devs have been maintaining packages / farming it out to community members, and while it isn’t unheard of or wrong for a community member to create a Flatpak for software they didn’t have a hand in coding, it isn’t really the ideal situation either.

        This is where the Flathub community will need to grow on their own. If they see that users want more CLI / TUI programs, they will need to take their own initiative and create the Flatpaks… but again, this isn’t ideal… the actual devs should do it, but not all devs can or will. Essentially, you’re talking about growing a new walled app garden infrastructure and hiring people to bring more apps into the fold and maintain them for security as well. Its not simple… and one of several reasons I personal don’t like Flatpaks

        Also keep in mind that certain software likely won’t ever be a Flatpak, like GCC etc, because it may be too close to the low level distro components and the distro devs will likely want it to remain non-Flatpak for their ease of updating the distro.

    • Falcon@lemmy.world
      1·
      10 months ago

      Worth mentioning that one can use bubblewrap directly over chroot to get similar behaviour as well.

      It’s often simpler to use distrobox but being able to rsync chroot a between devices can be very convenient.

  • EddyBot@feddit.de
    62·
    10 months ago

    If we are talking Silverblue then podman is your pick for everything Flatpack “can’t”
    there is no big push for cli flatpack since this already a solved cause with containers for podman/docker/kubernetes

    however no matter how you approach this you will always have dependency security issues
    unless you built every flatpack/container yourself you are at the whim of the creator of it to keep every dependecy updated
    this is already a known vulnerability factor in the container sphere on topbl of the threat of 0-day exploits

    • ElderWendigo@sh.itjust.works
      3·
      10 months ago

      I’m sure you know what you’re talking about. But your comment becomes a techno babble word salad when you throw in a typo or two, skip essential words and forego practically all correct use of punctuation and capitalization. I know this makes me sound old, dumb, and maybe a little mean. I know I’m old and dumb, but I’m really trying to not be mean.

  • ViciousTurducken@lemmy.one
    1·
    10 months ago

    VPN apps don’t seem to work with it and Proton said their Drive app won’t either. So for whatever reasons those might be.

  • ExtremeDullard@lemmy.sdf.org
    933·
    10 months ago

    Flatpaks are disk and memory hogs, and they start slowly. That’s because they’re like little selt-contained full-fledged operating systems.

    Flatpaks, like snaps, applimages, dockers, Electron apps, React apps or Flutter apps are the lazy 21st century developer’s way of achieving cross-compatibility without any effort.

    • DangerousInternet@lemmy.world
      111·
      10 months ago

      That is not true. Unless you run some electron app, which is like a browser, instead of making PWA, doing same thing. AppImages are dead. And Docker/Podman could be lazy developers, but you are still free to find an alternative?

    • Vojtěch Fošnár@beehaw.org
      112·
      10 months ago

      That’s not true and misleading. Docker and flatpak base images mostly contain shared libraries and even these get automatically deduplicated. Your flatpak calculator doesn’t ship systemd or any other init system nor does it ship system drivers lol

      And yeah if you are working in a restrained env and care about those few mbs taken by shared libraries then containarization is not for you.

      Containerization is not perfect and it will never be, but that was never the goal. Making apps and services independent of the base system and easily restrictable like mounting volumes, restricting network, etc… was.

      • ExtremeDullard@lemmy.sdf.org
        22·
        9 months ago

        I didn’t say they were the same thing. I said they’re what people do today to avoid having to port their code to different platforms and manage shared library versions, performances be damned.