Consider supporting AppImage assets for Linux

[apahl]

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]

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]

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]

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.

tool-sync/src/sync/archive.rs

Lines 41 to 79 in ca4855d

	pub fn from(
	archive_path: &'a PathBuf,
	tmp_dir: &'a Path,
	exe_name: &'a str,
	asset_name: &'a str,
	) -> Option<Archive<'a>> {
	let tar_gz_dir = asset_name.strip_suffix(".tar.gz");
	match tar_gz_dir {
	Some(tar_gz_dir) => Some(Archive {
	archive_path,
	tmp_dir,
	exe_name,
	archive_type: ArchiveType::TarGz(tar_gz_dir),
	}),
	None => {
	let zip_dir = asset_name.strip_suffix(".zip");
	match zip_dir {
	Some(zip_dir) => Some(Archive {
	archive_path,
	tmp_dir,
	exe_name,
	archive_type: ArchiveType::Zip(zip_dir),
	}),
	None => {
	let exe_file = asset_name.strip_suffix(".exe");
	exe_file.map(|_| Archive {
	archive_path,
	tmp_dir,
	exe_name,
	archive_type: ArchiveType::Exe(asset_name),
	})
	}
	}
	}
	}
	}

Adding support for this would also add some maintenance burden.

How common is this format?

[apahl]

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]

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]

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

tool-sync/src/sync/archive.rs

Lines 15 to 20 in 95f535c

	/// Archive type that specifies how to unpack asset
	enum ArchiveType<'a> {
	Exe(&'a str),
	Zip(&'a str),
	TarGz(&'a str),
	}

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).