Repository navigation
Support installing other archive formats #2899
Description
Description of the new feature / enhancement
Continuation of #140. See #140 (comment):
I agree that supporting other compression methods (zstd, lzma, etc.) and archive formats (7z, tar, etc.) is good and should eventually be added. Zips are the most common, so supporting just them is a good first step and I think it's better to have it ASAP and only after that think about other formats.
Other than .zip, most other software binaries are only available by either .7z and .rar. Examples:
- https://github.com/microsoft/TypeScript/releases/download/v7.0.2/typescript-win32-x64.tgz
- https://github.com/hashcat/hashcat/releases/download/v6.2.6/hashcat-6.2.6.7z
- https://sourceforge.net/projects/mpv-player-windows/files/release/mpv-0.35.1-x86_64.7z/download
Hopefully .7z and .rar gets added first, they're quite common. Other archive formats such as .tar, .gz, .zstd etc. can be added soon.
Proposed technical implementation details
No response
Activity
mloskot commentedon Apr 6, 2023
The lack of
.tar.gzsupport is a blocker for packaging Kuberneteskustomizetool, see microsoft/winget-pkgs#101705 and microsoft/winget-pkgs#101695superusercode commentedon May 23, 2023
https://blogs.windows.com/windowsdeveloper/2023/05/23/bringing-the-power-of-ai-to-windows-11-unlocking-a-new-era-of-productivity-for-customers-and-developers-with-windows-copilot-and-dev-home/
Will winget be able to use this functionality when it releases?
superusercode commentedon May 23, 2023
Demitrius Nelon (@denelon) I know this is really early but would winget be able to use the new archive support in windows 11 when it releases? I'm not sure how it will be implemented but I'd like to think it will be added to the existing APIs.
denelon commentedon May 25, 2023
Code. (@superusercode) yes, we want to see if it's possible to take advantage of the new features in libarchive to support more formats. As soon as we have time to dig into the new Insider version of Windows and figure out the right way to handle this in earlier versions of Windows (back compatibility is tricky) we want this capability.
kbdharun commentedon Jul 19, 2023
+1 for adding
7zsupport as it is the blocker for adding beta builds of Dolphin emulator to the manifest underDolphinEmulator.Beta.Dolphin.rollingmoai commentedon Sep 27, 2023
Demitrius Nelon (@denelon) Now that this has been released to stable, any chance that you will start looking at this?
lucasfcnunes commentedon Dec 3, 2023
Adding
.tar.bz2or.condaopens up the possibility of using the entireconda-forgebuilding system, which has more than 20k feedstocks.e.g.
https://anaconda.org/conda-forge/micromamba/files
https://anaconda.org/conda-forge/anaconda-project/files
https://anaconda.org/conda-forge/postgresql/files
https://anaconda.org/conda-forge/rust/files
https://anaconda.org/conda-forge/go/files
... and many more!
denelon commentedon Feb 17, 2024
I've been talking with several folks about support for some of the newer formats Windows 11 natively understands. The challenge here is that unless we pull libraries into WinGet or have WinGet install some other dependencies, users on earlier versions of the OS will not be able to install packages depending on the newly supported compression formats.
masterflitzer commentedon Feb 17, 2024
what about printing a message that their version of windows doesn't support e.g. tar.gz natively? this wouldn't make the experience of those users worse but it would improve the experience of users that use newer versions of windows
AnastasiyaSoyka commentedon Feb 17, 2024
I understand that locking out a substantial portion of the userbase who are using older versions of Windows is a very suboptimal solution.
However, over time, the number of users who are locked out of installing these packages will decrease, as users upgrade to newer versions of Windows.
Furthermore, it's not exactly unheard of for Windows to gate new features behind system updates. I feel like most users would understand this limitation as just another consequence of deferring timely updates.
solomoncyj commentedon Mar 26, 2024
this also allows interractive only installers to be installed if they are just a wrapper exe with the program files / msi underneath
pl4nty commentedon Oct 27, 2024
A lot of archive types work with
InstallerType: zipby settingarchiveExtractionMethodtotar, but malware scans fail (pure only supports zips), and the archives are renamed to.zipduring install. Maybe SmartScreen or AMSI could replace/complement pure?Tested
7z,rar,tgzandtbz2on Windows 22631.4391 with Winget v1.8.1911 and local manifests:pl4nty commentedon Nov 22, 2024
I've implemented AMSI to replace pure in #4910, would love some feedback. The default
archiveExtractionMethodwould also need changing totar, would that cause any problems?denelon commentedon Oct 13, 2025
Just adding a comment from the nerd-font project with a request to support .xz.
feat: add zip archives for Windows releases to support winget
dftf-stu commentedon Apr 9, 2026
I'm currently here on Windows 10 22H2 (OS Build: 19045.7058 ; March 2026 ESU)
I appreciate the native ability to extract 7z, BZip2, RAR, TAR and ZStandard won't be backported to Windows 10, but is there any-reason downloading of such files from WINGET cannot just be possible on this OS? (Like I'm sure many users on 10, I have the 7-Zip app installed, so can easily extract the file manually afterwards).
I assume (fairly new to WINGET) that something like
winget install example.package --installer-type ZIPwould then allow a ZIP to be extracted and installed, providing there was some sort of script file supplied?Surely the online help page for that command could simply show the limitations?
Supported installer formats
tianon commentedon Jun 5, 2026
I took the liberty of spending some "paperclip maximizer" tokens on the problem to demonstrate that it is indeed pretty trivial thanks to WinGet already having a
tar.exe-based install path: https://github.com/tianon-sso/winget-cli/compare/tar (permalinks: tianon-sso@47a1474 slash 47a1474) ❤️(I don't plan to open a PR because I don't have the spoons to shepherd this all the way through, but I'm happy to if a maintainer thinks it's worthwhile 👍 ❤️)#6278DandelionSprout commentedon Jul 11, 2026
Team RPCS3, whose app is in my eyes one of the holy grails that would've been fixed by this feature,⁽¹⁾ did… not exactly take it kindly when I proposed adding ZIPs alongside their 7Zs earlier today. At all. (
https://github.com/RPCS3/rpcs3/issues/19017)So overall, this issue report is stil as evergreenly relevant as it was when it was first created in 2023.
⁽¹⁾ = Alongside Tor Expert Bundle, which relies on .tar.gz.
DandelionSprout commentedon Jul 19, 2026
I've tried to look into winget-cli's code this afternoon to see if there's anything I could've contributed with in a PR, but I can't make heads or tails of the code if my life depended on it.
In particular, I can't find anything in the files that specify the parameters used by
tarwhen"archiveExtractionMethod": "tar"is set inwinget settings. As in, does it use-xfor not, or really if it uses anything or not?mcexit commentedon Jul 21, 2026
Imre Eilertsen (@DandelionSprout) It's admirable that you took the time to dive into the codebase, but honestly, why bother?
The most frustrating part of this entire situation is that the heavy lifting is already done at the OS level. Microsoft integrated native support for
.tar.gz,.tar,.zst,.7z,.rar, and so on, directly into Windows 11 via the open-sourcelibarchiveproject over two and a half years ago. Anyone can extract these archives natively in File Explorer right now.The underlying extraction mechanism is already built into the operating system. Bridging that gap in WinGet would require a relatively small time investment from the Microsoft-funded development team. Instead, this fundamental limitation has been actively neglected for over three years.
We shouldn't have to fight the package manager ("downloader") over standard upstream release formats just because Microsoft refuses to allocate the minimal engineering time required to connect the dots.
Because WinGet lacks this core functionality, prominent open-source projects are flooded with contentious requests to alter their release pipelines. It sets a terrible precedent when a heavily resourced project expects independent maintainers to carry the burden of bespoke "snowflake" artifacts just to cover for its own feature gaps. This negligence breeds active resentment across the broader development ecosystem. I'm actually left wondering if that is what Microsoft wants?
There seems to be a serious internal disconnect regarding what it takes to actually build a worthwhile package manager. If we rely on this issue tracker, we will likely be waiting another 3+ years while alternative package managers continue to move forward and actually serve developers' needs.
At this point, it will likely benefit Windows users more to explore those alternatives. For those who want to see WinGet actually succeed, the conversation will likely have to happen elsewhere. Writing blog posts and bringing public attention to these flaws might be the only way to get Microsoft leadership to prioritize a real solution, because trying to contribute here currently feels like a dead end.
DandelionSprout commentedon Jul 21, 2026
Regardless of how much Team Winget would deny the following, my qualified-but-still-wild guess is that the Microsoft CEOs in Silicon Valley spend 115% of their days talking, thinking, idolising, and dreaming about Copilot, and if anyone asked them about their package manager, the CEOs would go "…We have a package manager?"
If the CEOs decided to spend an extra US$100,000/year on 〜4 fulltime, contract-bound coders for Winget, which would be a drop in the ocean compared to the US$1,000,000,000,000,000,000,000,000,(etc.) it spends on Copilot, a whole lot of Microsoft projects would be happier.
——————————————————
DandelionSprout commentedon Jul 31, 2026
So I began thinking this afternoon, "Surely Scoop still has the potential to serve the non-ZIP market?", but I quickly realised that Scoop is for the most part worse-than-useless (or at least is bad enough that I take personal insult to Team Scoop about it), since they have for some ungodly reason never got around to implement any tag functions at all.
This means in the case of Tor Expert Bundle that users have to guess on that
toris that package, sincescoop search torexpertbundle,scoop search tor-expert-bundle, or anything similar would show no results.Probably related:
scoop searchScoopInstaller/Scoop#6055.