Will binstalk-downloader consider supporting 7z?

[ahaoboy]

https://github.com/cargo-bins/cargo-binstall/blob/main/crates/binstalk-types/src/cargo_toml_binstall/package_formats.rs

/// Binary format enumeration
#[derive(
    Debug, Display, Copy, Clone, Eq, PartialEq, Serialize, Deserialize, EnumString, EnumIter,
)]
#[serde(rename_all = "snake_case")]
#[strum(ascii_case_insensitive)]
pub enum PkgFmt {
    /// Download format is TAR (uncompressed)
    Tar,
    /// Download format is TAR + Bzip2
    Tbz2,
    /// Download format is TGZ (TAR + GZip)
    Tgz,
    /// Download format is TAR + XZ
    Txz,
    /// Download format is TAR + Zstd
    Tzstd,
    /// Download format is Zip
    Zip,
    /// Download format is raw / binary
    Bin,
}

[NobodyXu]

Yes, if there's a rust crate for 7z then I'm willing to support this

[ahaoboy]

Yes, if there's a rust crate for 7z then I'm willing to support this

Unfortunately I didn’t find a reliable 7z library :(

[NobodyXu]

I do know there's a deflate64 that I think is somehow related to 7z, but not sure about library.

[WyvernIXTL]

There is https://github.com/hasenbanck/sevenz-rust2

I have not reviewed its code or tested it out, but it looks promising.

Then there is also https://github.com/OSSystems/compress-tools-rs

[WyvernIXTL]

As 7zip is natively supported on Windows 11, there is not much reason for me to compress my binaries with zip. 7zip is faster, more efficient and faster.

The only other format that has some semblance of popularity on Windows is RAR. But that's a no go with CI.

Scoop also supports 7zip. Though I think 7z is being installed automatically or must be in PATH.

What speaks against checking for 7z being in PATH and using it if it exists?

[passcod]

Windows 11 also supports tar.xz (among many other things, but that's the closest to 7z), so that's not really an argument for or against when choosing a format.

We've chosen to have all the decompressors in-binary so that the support for files is not environment-dependent. Think like, if you want to test on Win10 or Server2022 and whoops, the tool is unavailable because upstream used 7z and your user doesn't have that, even if it worked on your Win11 workstation.

[NobodyXu]

I have not reviewed its code or tested it out, but it looks promising.

Generally we want something well-maintained, and does not contain any malicious code (recent xz2 backdoor really reminds me how important it is), and ideally, support async, or uses sans-IO, though we can work with blocking IO 7z implementation.

[WyvernIXTL]

Windows 11 also supports tar.xz

Scoop extracts such formats also with 7z 🤔. Maybe it also supports .tar.xz. I'd have to test that.

Though I expect that normal people will not understand that format. Even if Windows supports it... I have seen a person "having to install" WinZip with free trial just to unzip a ZIP... 🙁 That person was a computer science student and not a granny. 😓

I could then again just compress with CI to zip, 7zip and tar.xz. This will absolutely clutter the release page. My in between measure was just to give up on the lost souls that cannot extract 7z on windows or tar.xz on unix.

[WyvernIXTL]

7z worked just fine for me on my Windows PC for creating .tgz, .txz and .tar.xz. In my github workflow it did not.

The only way to make binstall usable in my case at this moment, is to create .zip files...

The case for .7z support:

• 7zip archives are smaller than zip archives.
• 7zip archives most often extract faster when being confronted with many small files.
• 7zip archives are a generally accepted format for distributing binaries on Windows.
• 7zip does not want to produce txz or tgz archives on a GitHub action runner at this moment ;-;
• As other tools like Scoop support 7zip and binstall does not, and as .7z is a much more common file format than .tar.xz on Windows (.txz cannot be extracted on Windows natively) , multiple versions of a release binary have to be present on the release page of a GitHub repo for optimal download speeds with either tool and for acceptance from the user base.