Support 'unar' instead of requiring various unpackers (e.g. xz)

[docwhat]

Is your feature request related to a problem? Please describe.

I'm frustrated when something requires an unpacker, such as xz.

Describe the solution you'd like

Recognize and support unar for unpacking archives.

Bonus points for adding a Zinit pack/annex (not sure which would be applicable here).

Describe alternatives you've considered

You gotta help us, Doc. We've tried nothin' and we're all out of ideas.

[alichtman]

Can you show me something that requires an unpacker?

[docwhat]

Note my has'xz' that I just added to prevent it borking the install and requiring a zi delete.

zinit wait lucid for \
  from'gh-r' \
  as'program' \
  has'xz' \
  mv'shellcheck* -> shellcheck' \
  pick'shellcheck/shellcheck' \
  @koalaman/shellcheck

[pschmitt]

I can see this within zinit's core.

If there's $fancy_archive_extractor, then use it.

ziextract should be relatively easy to patch: https://github.com/zdharma-continuum/zinit/blob/5df5fb6b4673939b3f23d579a132fc7b701e09a4/zinit-install.zsh#L1526-L1827

What I don't like about that idea though is that while you mention unar, there's a ton of alternatives. What $fancy_archive_extractor should we support?

borking the install and requiring a zi delete.

What exactly do you mean by that?

[alichtman]

If we support installing packages from GH Releases, we must support decompressing them. I think it's reasonable to add support like this.

This is essentially what unar does, to the best of my knowledge. We can reimplement it, or just declare unar as a dependency.

[pschmitt]

If we support installing packages from GH Releases, we must support decompressing them. I think it's reasonable to add support like this.

That is supported already. I've literally linked to the implementation above :) zinit can already extract archives. This issue is about whether ziextract should try unpacking with unar before falling back to the individual tar, unzip, unrar etc commands.

[alichtman]

Hah, right. I see that now. Ignore my comment above. I was thinking we only supported shell scripts and executables.

I don't use this feature, so I'm not super knowledgeable about it.

[vladdoster]

@docwhat,

Can this be closed?

[docwhat]

What I don't like about that idea though is that while you mention unar, there's a ton of alternatives. What $fancy_archive_extractor should we support?

It's true. There are a lot.

zi could just fetch unar (or some other unpacker) for its own use instead of depending on the system's unpacker.

borking the install and requiring a zi delete.

What exactly do you mean by that?

I don't remember exactly anymore.

I think I had unar but didn't have xz. The unpack failed, and zi didn't know since there was a directory present.

Fixing it required figuring out what happened, installing xz, and deleting the package so it could reinstall.

[docwhat]

This issue is about whether ziextract should try unpacking with unar before falling back to the individual tar, unzip, unrar etc commands.

At least, unar should be tried. I had unar available but didn't have xz.

[docwhat]

Can this be closed?

I'd prefer if unar was added to ziextract.

[vladdoster]

@docwhat,

I, too, have been on systems or in containers that do not have xz (xz-utils on Ubuntu), file, or unzip.

The most portable solution is to try using python3 modules (e.g., lzma, zip, etc.) and fallback to install programs. I think Python3 will solve most issues of missing archive tools.

Thoughts?

[vladdoster]

I just stumbled upon this rust utility you might like.

https://github.com/ouch-org/ouch