I created a script for installing Linux apps from their official sources
-
I created a script that always installs apps from their official source
https://github.com/Tsu-gu/appfetch/
It's a proof of concept of an idea I had a while ago. I dislike having to hunt down apps for my Linux machine when I want them from an official source. Some apps are packages as tarballs, some as .debs, some as install scripts that download a binary, some are flatpaks and snaps.
I created a yaml file with only verified apps from flathub and snapcraft, and added a few apps outside of them that I could think of.
The ultimate goal is the user just typing the names of what they want, and the script will just get it. They shouldn't waste time with picking the right source.
-
I created a script that always installs apps from their official source
https://github.com/Tsu-gu/appfetch/
It's a proof of concept of an idea I had a while ago. I dislike having to hunt down apps for my Linux machine when I want them from an official source. Some apps are packages as tarballs, some as .debs, some as install scripts that download a binary, some are flatpaks and snaps.
I created a yaml file with only verified apps from flathub and snapcraft, and added a few apps outside of them that I could think of.
The ultimate goal is the user just typing the names of what they want, and the script will just get it. They shouldn't waste time with picking the right source.
I like the idea ! And looked at the project on github. But ..... snap disgust me so much more than searching the right source, i'm not adapting to it. But still nice thinking!
-
I like the idea ! And looked at the project on github. But ..... snap disgust me so much more than searching the right source, i'm not adapting to it. But still nice thinking!
Thank you, and fair enough.
-
Thank you, and fair enough.
Maybe add something in the search results to indicate the app's origin? Or even just a way to choose search sources?
-
I created a script that always installs apps from their official source
https://github.com/Tsu-gu/appfetch/
It's a proof of concept of an idea I had a while ago. I dislike having to hunt down apps for my Linux machine when I want them from an official source. Some apps are packages as tarballs, some as .debs, some as install scripts that download a binary, some are flatpaks and snaps.
I created a yaml file with only verified apps from flathub and snapcraft, and added a few apps outside of them that I could think of.
The ultimate goal is the user just typing the names of what they want, and the script will just get it. They shouldn't waste time with picking the right source.
Sounds like Obtainium on Android.
The thing that concerns me is that it downloads an unofficial source.
-
Maybe add something in the search results to indicate the app's origin? Or even just a way to choose search sources?
I understand that people treat snap as if it was a contagious virus but the developers chose the method purposely. A lot of KDE apps are only distributed as snaps for example, k3b comes to mind. VLC as well.
There are flatpak versions but they aren't official, which defeats the point a bit.
I do however plan to somehow add the ability to prefer flatpak, since a few of the entries have both a flatpak and snap field.
-
Sounds like Obtainium on Android.
The thing that concerns me is that it downloads an unofficial source.
Those are all official sources tho, but you have to trust me not to put in malicious commands of course.
-
Those are all official sources tho, but you have to trust me not to put in malicious commands of course.
Oh so you are essentially personally maintaining the sources list?
-
Oh so you are essentially personally maintaining the sources list?
wrote last edited by [email protected]Yep. I did automate it the best I could (I'm not creating entries for thousands of apps manually) but it will indeed require manual maintenance as the apps will change their installation methods over time.
-
I understand that people treat snap as if it was a contagious virus but the developers chose the method purposely. A lot of KDE apps are only distributed as snaps for example, k3b comes to mind. VLC as well.
There are flatpak versions but they aren't official, which defeats the point a bit.
I do however plan to somehow add the ability to prefer flatpak, since a few of the entries have both a flatpak and snap field.
the developers chose the method purposely
They chose it because it's often the only way they can distribute packages to Ubuntu users. Which was the whole point all along; Canonical taking control of app distribution.
-
the developers chose the method purposely
They chose it because it's often the only way they can distribute packages to Ubuntu users. Which was the whole point all along; Canonical taking control of app distribution.
wrote last edited by [email protected]But why choose snap only? Flatpak works on Ubuntu just fine, and on other distros obviously, so they could just choose that. Blender only officially support snap too. Vivaldi for example made a blog post about how snap has better sandboxing of chromium. https://social.vivaldi.net/@ruario/113164179328218870
-
I created a script that always installs apps from their official source
https://github.com/Tsu-gu/appfetch/
It's a proof of concept of an idea I had a while ago. I dislike having to hunt down apps for my Linux machine when I want them from an official source. Some apps are packages as tarballs, some as .debs, some as install scripts that download a binary, some are flatpaks and snaps.
I created a yaml file with only verified apps from flathub and snapcraft, and added a few apps outside of them that I could think of.
The ultimate goal is the user just typing the names of what they want, and the script will just get it. They shouldn't waste time with picking the right source.
I think that using some "custom" package names for internal args is not the best choice.
Anyway, later I'll take a better look at it and probably contribute to it. Ty
-
I think that using some "custom" package names for internal args is not the best choice.
Anyway, later I'll take a better look at it and probably contribute to it. Ty
Could you elaborate? I'm not the best programmer so I'm open to suggestions.
-
Could you elaborate? I'm not the best programmer so I'm open to suggestions.
wrote last edited by [email protected]I saw that "version" and "update" are inside apps.yaml instead inside the program itself like "search". I see why version helps to be there which gets updated with the list, but the update link looks more like a quirk to be inside apps list.
And it would make sense to distinguish program version and apps list version. -
I saw that "version" and "update" are inside apps.yaml instead inside the program itself like "search". I see why version helps to be there which gets updated with the list, but the update link looks more like a quirk to be inside apps list.
And it would make sense to distinguish program version and apps list version.That's a good point. I will also probably need a better update method than rm -rf-ing the files and replacing them with each update.
-
I created a script that always installs apps from their official source
https://github.com/Tsu-gu/appfetch/
It's a proof of concept of an idea I had a while ago. I dislike having to hunt down apps for my Linux machine when I want them from an official source. Some apps are packages as tarballs, some as .debs, some as install scripts that download a binary, some are flatpaks and snaps.
I created a yaml file with only verified apps from flathub and snapcraft, and added a few apps outside of them that I could think of.
The ultimate goal is the user just typing the names of what they want, and the script will just get it. They shouldn't waste time with picking the right source.
Genuine question: Why would I use this as opposed to Nix? Between nixpkgs and the NUR, there are an insane amount of packages available, and you can build everything from source if you wish.
-
Genuine question: Why would I use this as opposed to Nix? Between nixpkgs and the NUR, there are an insane amount of packages available, and you can build everything from source if you wish.
It's meant for people who prefer their apps from the official sources rather than repackaged. All this script dies is make it easy so you don't have to google the app's name and search for an install method on its website.
-
It's meant for people who prefer their apps from the official sources rather than repackaged. All this script dies is make it easy so you don't have to google the app's name and search for an install method on its website.
right, that's what nix does if you build from source
-
right, that's what nix does if you build from source
If you want to build from source, this brings nothing of value. Nix has pretty much everything.
-
If you want to build from source, this brings nothing of value. Nix has pretty much everything.
with that being the case, correct me if I'm wrong, but your pitch is that users should trust your manually compiled and maintained commands to install things because you're guaranteeing that the binaries being installed by your commands are from official sources, and that is better (in at least some cases) than cached binaries from something like nixpkgs, where the trust we are asked to give is that the cache is built correctly from source.
