search

chshersh / tool-sync

🧰 Download pre-built binaries of all your favourite tools with a single command
https://crates.io/crates/tool-sync
Mozilla Public License 2.0
69 stars 16 forks source link

Consider supporting AppImage assets for Linux #129

Open apahl opened 1 year ago

apahl commented 1 year ago

Hi, thanks a lot for this project, I love it!
Very useful when one works with a number of tools and programs outside of the distro's package manager, which I do.

I don't know how much effort it would be, but maybe you could consider to also support AppImage assets?

Kind regards,
Axel

MitchellBerend commented 1 year ago

I don't know how much effort it would be, but maybe you could consider to also support AppImage assets?

I have personally never heard of Applmage from the stuff I googled it either looks like a package manager or an image format. tool-sync only downloads binaries and puts them in a designated places.

What would supporting this look like conceptually?

apahl commented 1 year ago

No expert for AppImages myself, but they are executable archives for Linux. They contain the binary and all necessary resources (libraries and stuff) and can be directly executed.
For that reason they tend to be quite large and are a relatively common means of distribution for Electron apps on Linux. The big advantage is, that one only has to download the AppImage file, set the executable bit and run it. No further extraction needed.

For example, one note taking tool that I use daily and that offers this form of distribution is Logseq. I use Logseq on a daily basis and it is updated frequently (this would be my concrete "use case").

KR Axel

MitchellBerend commented 1 year ago

I personally don't use any Applmages apps myself (probably since I always just default to musl if possible) but here is the bit that is responsible for checking whether or not the asset type is supported.

https://github.com/chshersh/tool-sync/blob/ca4855dc191a4edc13f09624e88e5ce7966e5122/src/sync/archive.rs#L41-L79

Adding support for this would also add some maintenance burden.

How common is this format?

apahl commented 1 year ago

Well for me it is quite common, I have at least 3 apps on my system that use this means of distribution.
But ofc I do not know how representative that is.

I agree that it would require a quite significant change to the code and propose to close this issue for now.
Thanks a lot for the quick response.

KR Axel

MitchellBerend commented 1 year ago

I would like to keep this issue open for others to potentially give some input on this since this issues is less than 24 hours old. I don't think more eyes on this wouldn't hurt.

chshersh commented 1 year ago

I believe supporting AppImage wouldn't be too much difficult. It's just a matter of adding one more asset type here:

https://github.com/chshersh/tool-sync/blob/95f535cdbdc8fd4305b1378688fcc4e53c0b2bff/src/sync/archive.rs#L15-L20

Renaming ArchiveType to smth else would be nice as well since it's already not an archive, and maybe the entire module shouldn't be archive.rs but oh well

And then patching the from method in the impl Archive as mentioned by @MitchellBerend. Currently, the implementation of this method is a bit ugly (and I'm not happy with it but it does the job). Would be nice to refactor it as well because I imagine we would add more asset types in the future (e.g. bz2).

Since AppImage doesn't require any unpacking and it behaves just like .exe, supporting this asset type should be easy.

⚠️ The only difficult question is whether we should prefer AppImage over .zip or not. I don't know the answer 🤔 But maybe it's not that important. Maybe we can default to .zip as a known beast and fallback to AppImage only if we don't find .zip (should be easily expressable with my idea in #50). Users always can specify their own version if they want AppImage (following the discussion under #116).