Support installing .zip files
I want to be able to have winget install apps inside of .zip files.
Related to:
- https://github.com/microsoft/winget-cli-restsource/issues/117
Proposed technical implementation details (optional)
This would enable Winget to support all the Sysinternals tools.
What would we want to happen here? specify in the yaml where we want the folder to be unzipped to? Or ask the user where to unzip to?
https://github.com/microsoft/winget-pkgs/issues/174
@aclinick - Installing ZIP files could also help support the very long tail of stand-alone and other common tools & utilities, esp. command-line tools like curl, and others that are distributed via ZIP.
Have reached-out to curl re. signing their tools and building an MSI/MSIX.
This would be great! Gradle has always required a package manager on Windows (I'm currently using it with Scoop) and having it on winget would be fantastic, but it's a .zip file.
Also, wouldn't zip files (and standalone .exe apps) require some more complicated setup steps that would have to be described in winget's YAML file? e.g. adding things to PATH, creating a desktop link, creating a Start menu entry etc.
This would be great! Gradle has always required a package manager on Windows (I'm currently using it with Scoop) and having it on winget would be fantastic, but it's a .zip file.
Also, wouldn't zip files (and standalone .exe apps) require some more complicated setup steps that would have to be described in winget's YAML file? e.g. adding things to PATH, creating a desktop link, creating a Start menu entry etc.
And environment variable.
I think there should be a default Apps folder maybe within the %USERPROFILE%. Unzipped zips should be per default copied there maybe within a subfolder. The same may also happen for PowerShell Scripts (PS1) and EXEs. An additional parameter may choose another folder where the package is copied to.
I was about to create a manifest for Paint.net when I noticed that .zip is not supported... yet! 🙂
A lot of .msi installers are packed into .zip files because you cannot execute .msi downloaded from internet. ;-)
I wanted to add PostgreSQL support, but lack of zip extraction is a problem here.
related to https://github.com/microsoft/winget-pkgs/issues/580
Right now Winget can't be used to package/install anything without complex installers.
I think there are actually two issues or requests related to ZIP:
- Support software that is provided as ZIP archives for plain xcopy deployment
- Support installers (MSI, EXE, etc.) that are made available for download in a ZIP file (e.g. https://mh-nexus.de/de/downloads.php?product=HxD20)
@aclinick, ideally it would be a) unzip a ZIP file; b) (optionally) run a batch file script to perform some configuration. Would be reasonable if there's also an uninstall script that reverses the latter.
We'd use this for installing Dart and Flutter on Windows.
I'd suggest ZIP support with a parameter to install to either Program Files or a specified location given in the command
If we have a solution that works for everybody (Scoop), why trying to duplicate it?
@aclinick, ideally it would be a) unzip a ZIP file; b) (optionally) run a batch file script to perform some configuration. Would be reasonable if there's also an uninstall script that reverses the latter.
Having your PowerShell scripts in the zip to be executed opens up a lot of options to universally install anything. PowerShell can be used to fill any gaps that WinGet has not covered yet. Every one of my custom Chocolatey packages is basically a folder full of files with an install.ps1.
A good example is something like #166 where someone needs to install fonts.
Adobe Creative Cloud is another example of an installer inside a zip file: https://ccmdl.adobe.com/AdobeProducts/KCCC/CCD/5_1/win64/ACCCx5_1_0_407.zip
This seems like the installer that supports silent installation, not the smaller one that requires an internet connection.
It seems that "tar.exe" is a part of Windows 10, so this could be really useful.
@tap52384 😲
I think we need to support installing standalone binary only tools like kubectl where you typically just download a exe and put into your path. That leads to the question where in path to put it?
This is how a lot of modern developer tools are distributed
Or... post an issue on @Sysinternals to publish their packages as MSIX?
Or... post an issue on @Sysinternals to publish their packages as MSIX?
There are ton of tools which doesnt need an installer, sysinternals is just one of them.
You download an exe add it to path and thats it. I usually preferr them, no hastle at all. And should be easy to implement for winget too.
Curl, minkube, github cli, putty, or all sysinternals tool as you mentioned. Or any go executable/programm... even adoptopenjdk would offer a api for downloading zip.
Or... post an issue on @Sysinternals to publish their packages as MSIX?
There are ton of tools which doesnt need an installer, sysinternals is just one of them.
You download an exe add it to path and thats it. I usually preferr them, no hastle at all. And should be easy to implement for winget too.
Curl, minkube, github cli, putty, or all sysinternals tool as you mentioned. Or any go executable/programm... even adoptopenjdk would offer a api for downloading zip.
That's exactly what you have in scoop - extracts the zip file and creates a shim to the exe. Shims folder is in the path.
We can use scoop and winget in parallel, or take the functionality from scoop and add it to winget if we want the whole solution in one place.
+1 for adding the ability to execute a .ps1 or .bat script after extracting a ZIP file. Ideally, this should be a file that may not be included in the original package. This should allow us to work with most types of packages distributed as ZIP files.
For example, MSI Afterburner setup is distributed in a ZIP file. Ideally, we should be able to include the script along with the manifest in winget-pkgs as well.
I will add a +1 that this feature is required for useful deployment of many cross platform toolchains. Distributing binaries on github release pages is fairly common practice.
IMO Sysinternals could use an installer so I created one at https://github.com/iswix-llc/SysinternalsSuiteInstaller
-
Prompt user for location to download zip from (self hosting offline scenarios) (Default Microsoft URL for silent/winget installation)
-
Download and extract ZIP to installation directory
-
Place installation directory at end of system path
-
Create start menu shortcut that points to installation directory.
UX is vastly improved. PR submitted:
https://github.com/microsoft/winget-pkgs/pull/1288
@WtfJoke what's confusing? This is basically how most choco packages do it. They have a chocolateyInstall.ps1 that downloads content from the vendor and then runs the installation commands. Their nuspec file doesn't typically have the actual content because of legal redistribution rights issues.
Confusion smiley is maybe not the right one. But In my opinion its not a solution to build for every tool an installer, because of a lacking feature of winget itself.
So rather than patchworking for various software we should get it fixed/enhanced.
However I appreciate the work you put into it. Personally I wouldnt use it, since an unofficial installer is less trustworthy for me (I am aware of that yours probably is). Hope you understand
I work in EUC for a fortune 30 company. I oversee the deployment of thousands of applications to 180,000 windows devices. My life would be A LOT easier if every tool had an installer. Tools such as WinGet, SCCM and Intune have application models. When the app fits the model it just works. When apps doing anything and everything they want it becomes impossible to create automation to support everything. I hope you understand too.
After crating hundreeds of packages for various platforms and recently mostly working Chocolatey packages where I develop and maintain coreteamrepo I must say that PowerShell scripting within package should get TOP priority. Its simply not possible to do anything more complex relying only on yaml declarations and any "native" method (like ZIP extraction) will only reinvent the weel in a bad way.
Zip files aren't packages or installers. They are just archives that have no additional meta / context or standardized entry point for business rules / setup logic. This feature request should be a non starter.
A .ZIP installer would be a good addition.
If you look at how Instal-PowerShell.ps1 script, used to install PowerShell 7 works. It enables a simple zip "installer" which is really just a find/download the zip file then expand it into the specified folder. Shouldn't Winget do something similar - if the manifest says zip, then just download it and expand it and let the user go from there.
And of course, if there was some way to indicate that winget should create desktop/taskbar shortcuts to the relevant .exe in that expanded folder, double sweet.