Today I had to downgrade fastapi from 0.114.0 to 0.112.4 to make a software work. And it just hit me - what if pip didn’t support 0.112.4 anymore? We would lose a good piece of software just because of that.

Of course, we can “freeze” the packages into an executable that will run for as long as the OS supports it. Which is a lot longer. But the executable is closed source. We can’t see the code that is run from an executable.

Therefore, there is a need for an alternative to which we still have access to the packages even after the program is built. That would make it safely unnecessary for pip to store all versions of all packages forever more.

Any ideas?

  • @badcommandorfilename
    -3•2 months ago

    Isn’t this the whole idea behind flatpak but everyone seems to hate it

      • @[email protected]
        8•2 months ago

        I hate them ! How can something be flat and a package at the same time ? Those flatpackers are the flatearther conspirators of IT ! Just burn them on hot pile of logs like we are in the 17th century !!! Burrrrn !!!

      • @[email protected]
        5•2 months ago

        I hate them (seriously).

        It’s basically a second distro inside your distro (try du -chs /var/lib/flatpak/) and if something breaks (eg. last year mesa with my graphics card) it isn’t easy to identify were the problem is (because all libs update at the same time), plus you can’t just try a newer (or older) version of some lib as you would in your distro.

        Moreover, you can’t flatpak CLI tools (also servers and OS components, but I guess the ubuntu folks are the only ones who care about those).

        • @[email protected]
          1•2 months ago

          So, I’m not gonna pretend flatpak doesn’t use more space then normal apps, but due to deduplication (and sometimes filesystem compression), flatpaks often use less space than people think.

          [nix-shell:~/Playables/chronosphere]$ sudo /nix/store/xdrhfj0c64pzn7gf33axlyjnizyq727v-compsize-1.5/bin/compsize -x /var/lib/flatpak/
Processed 49225 files, 21778 regular extents (46533 refs), 22188 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       53%      898M         1.6G         3.6G
none       100%      499M         499M         1.0G
zstd        34%      399M         1.1G         2.6G

[nix-shell:~/Playables/chronosphere]$ du -sh /var/lib/flatpak/
1.7G    /var/lib/flatpak/

          I only have one flatpak app installed, and du says that takes up 1.7 GB of space… but actually, when using a tool that takes up BTRFS transparent compression into account, only half of that space is used on my disk.

          I recommend using compsize for a BTRFS compression aware version of du and flatpak-dedup-checker for a flatpak filesystem deduplication aware checker of space used.

          I think flatpak absolutely does use up more space, because yes, it is another linux distro in your distro. But I think that’s a tradeoff people accept in order to have a universal package manager for graphical apps.

          Also, you can flatpak cli tools. They are just difficult to run at first because you have to do the flatpak run org.orgname.appname thing, but you can alias that to a short command. Here is a flatpak of micro, a terminal based text editor.

          (I prefer nix for cli tools though, and docker/podman/containers for services).

        • Captain Beyond
          1•2 months ago

          This is why the marketing around flatpak bothers me. It’s touted as some kind of “universal Linux package manager” but Linux is just a kernel - all the stuff that apps depend on comes with the distro. So, in order for flatpaks to be “distro independent” they basically have to supply all the stuff that normally comes from the distro - effectively building a second distro on top of your existing one.

          Nix and Guix are the same but at least I think they’re more up front that they are effectively distros that can run on top of your existing distro or as a standalone operating system directly on top of Linux.