search

microsoft / winget-cli

WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
https://learn.microsoft.com/windows/package-manager/
MIT License
23.12k stars 1.44k forks source link

Support installing .zip files #140

Closed denelon closed 2 years ago

denelon commented 4 years ago

I want to be able to have winget install apps inside of .zip files.

Related to:

Proposed technical implementation details (optional)

markrussinovich commented 4 years ago

This would enable Winget to support all the Sysinternals tools.

aclinick-zz commented 4 years ago

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?

denelon commented 4 years ago

https://github.com/microsoft/winget-pkgs/issues/174

bitcrazed commented 4 years ago

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

utybo commented 4 years ago

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.

zuozishi commented 4 years ago

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.

DennisGaida commented 4 years ago

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.

pedrolamas commented 4 years ago

I was about to create a manifest for Paint.net when I noticed that .zip is not supported... yet! 🙂

pashagolub commented 4 years ago

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.

maxandersen commented 4 years ago

related to https://github.com/microsoft/winget-pkgs/issues/580

Right now Winget can't be used to package/install anything without complex installers.

chausner commented 4 years ago

I think there are actually two issues or requests related to ZIP:

  1. Support software that is provided as ZIP archives for plain xcopy deployment
  2. 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)
timsneath commented 4 years ago

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

marypcbuk commented 4 years ago

I'd suggest ZIP support with a parameter to install to either Program Files or a specified location given in the command

shayvt commented 4 years ago

If we have a solution that works for everybody (Scoop), why trying to duplicate it?

KevinMarquette commented 4 years ago

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

tap52384 commented 4 years ago

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.

bitcrazed commented 4 years ago

@tap52384 😲

benc-uk commented 4 years ago

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

ElSrJuez commented 4 years ago

Or... post an issue on @Sysinternals to publish their packages as MSIX?

WtfJoke commented 4 years ago

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.

shayvt commented 4 years ago

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.

UzEE commented 4 years ago

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

bpbradley commented 4 years ago

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.

chrpai commented 4 years ago

IMO Sysinternals could use an installer so I created one at https://github.com/iswix-llc/SysinternalsSuiteInstaller

  1. Prompt user for location to download zip from (self hosting offline scenarios) (Default Microsoft URL for silent/winget installation)

  2. Download and extract ZIP to installation directory

  3. Place installation directory at end of system path

  4. Create start menu shortcut that points to installation directory.

UX is vastly improved. PR submitted:

https://github.com/microsoft/winget-pkgs/pull/1288

chrpai commented 4 years ago

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

WtfJoke commented 4 years ago

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

chrpai commented 4 years ago

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.

majkinetor commented 4 years ago

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.

chrpai commented 4 years ago

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.

doctordns commented 4 years ago

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.

marypcbuk commented 4 years ago

the problem with saying that Zip files should be out of scope because they aren't packaged installers is that would be the package manager trying to dictate the distribution format or hundreds of thousands of existing software tools, when Zip has been used as a distribution format for as many decades as I've been in the industry; to be useful, a Windows package manager needs to support the enormous variety of software out there that is one of the reasons Windows is so enduring an OS.

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.

chrpai commented 4 years ago

Platforms have always set the standards for apps that run on then. The problem is enforcement has been weak. ISVs can and do put just about anything into a .ZIP and call it done. Then I read comments from people that want the pkgmgr to do stuff with it like.

1) set destination directory 2) put application directory path or not 3) create shortcuts (path / name ) or not...

So just how are you supposed to do that programatically with no standard zip file format and no manifest / meta?

marypcbuk commented 4 years ago

there are several comments in this thread already with design suggestions for that like https://github.com/microsoft/winget-cli/issues/140#issuecomment-632751027

majkinetor commented 4 years ago

Then I read comments from people that want the pkgmgr to do stuff with it like.

Yes, package script should be able to implement its own installer, if that is what one desires. I have done so in countless occassions. Just because vendor zips it, put a huge web page with instructions and call it a day doesn't mean we should follow up.

For example:

Those are just couple of tools that are extensivelly used and didn't provide install option. Its typical for jar applications to not have provided any installer options beside puting them in zip archive, so in order to be useful, you need to do so - you can't just dump jar on the path and call it a day.

marypcbuk commented 4 years ago

@majkinetor what a great way for the community to improve things ;)

Witchilich commented 4 years ago

Not just zip files. To support all portable apps it should support 7z and cab files, and also things like youtube-dl. I dont know how you can implement yori in winget. https://github.com/malxau/yori/issues/43 It is in Scoop https://github.com/ScoopInstaller/Main/blob/master/bucket/yori.json winget should also add shims for these apps and support powershell commands or scripts during installation and uninstallation https://github.com/microsoft/winget-cli/issues/361 The aim should be portable apps support of the same level as Scoop.

Witchilich commented 4 years ago

I will also add, winget should be able extract installers from exes https://download.microsoft.com/download/8/4/A/84A35BF1-DAFE-4AE8-82AF-AD2AE20B6B14/directx_Jun2010_redist.exe

megamorf commented 4 years ago

I will also add, winget should be able extract installers from exes https://download.microsoft.com/download/8/4/A/84A35BF1-DAFE-4AE8-82AF-AD2AE20B6B14/directx_Jun2010_redist.exe

Why? Those typically have switches to pass parameters to the embedded msi files.

Witchilich commented 4 years ago

I will also add, winget should be able extract installers from exes https://download.microsoft.com/download/8/4/A/84A35BF1-DAFE-4AE8-82AF-AD2AE20B6B14/directx_Jun2010_redist.exe

Why? Those typically have switches to pass parameters to the embedded msi files.

This one does not. You need to extract it with .\directx_Jun2010_redist.exe /Q /T:C:\directx and then install through dxsetup.exe with /silent. winget has to extract it on its own, so that we can pass the silent argument.

ckarcz commented 4 years ago

instead of of supporting zip files (there are so many archive formats), why not have the manifest/winget have install script / uninstall scripts. that opens the door for zips, rar, 7z, fonts, or just arbitrary scripts that configure windows even.

magicgoose commented 4 years ago

instead of of supporting zip files (there are so many archive formats), why not have the manifest/winget have install script / uninstall scripts. that opens the door for zips, rar, 7z, fonts, or just arbitrary scripts that configure windows even.

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.
Also I don't agree that it should complicate manifests in any way that requires scripting.
Manifests should be as easy as possible to write and maintain, because that's going to be the primary factor affecting the quantity of available software.

jamesgecko commented 3 years ago

If we have a solution that works for everybody (Scoop), why trying to duplicate it?

This is a more recent thing, but Scoop development seems to be stalling out. The Scoop GCC package and all packages that depend on it have been broken for weeks. Chocolatey may soon be the only popular package manager that can install applications distributed via zip.

kindrowboat commented 3 years ago

I noticed that this was assigned to a milestone that is now past due, but no one is assigned to it on Github. Is this being working on by someone at Microsoft? Is a pull request from the community welcome?

denelon commented 3 years ago

@motevets, we're just using milestones for sequencing. It's not being worked on yet. We're planning on tackling this with support for standalone .exe binaries at the same time.

Part of the work will be to consider adding an ARP entry so these kinds of packages can be upgraded and removed. That would include adding and removing the appropriate path.

We'd be thrilled to have PRs from the community. The first part would be adding a feature toggle. Is this something you'd be interested in contributing to? I'd be happy to help work on a spec to capture the desired behavior and path as well as the changes to the schema and our validation mechanisms.

kindrowboat commented 3 years ago

Yeah, I'd be interested in contributing. 😄

JohnMcPMS commented 3 years ago

This, and any other installer type where the actual file staging is handled by winget directly, will require the unvirtualizedResources capability to be added to the MSIX package manifest. In addition, we will need to use this to disable the file and registry virtualization via the referenced manifest elements.

File write virtualization needs to be disabled to allow the user to specify the location where the files will be placed. It also gives us more flexibility to choose the default location.

Registry write virtualization needs to be disabled as we plan to write Add/Remove Program (ARP) entries for these. This will allow a path for these packages to show up in the standard Windows flows for managing installed applications. In addition, updating the user's stored path requires it (/speculation).

Note that the ability to disable virtualization was introduced in Windows 10.0.18362 (aka May 2019, 1903, or 19H1), and thus there will be cases where we do still have virtualization. After some discussion, we have decided that this is acceptable for registry and we will need to write some code to ensure that files are not virtualized. This will mean a limit on the locations that a pre-18362 client will be able to install to.

@motevets , I think you will probably want to apply the above capability and manifest elements to the dev package while you are working on it, otherwise there could be some nice long, confusing investigations on where your successful registry/file writes are ending up. 😃 We are also happy to accept any level of contribution, and I can understand not wanting to do the work to support the older OS. Someone will need to do it before the feature can be enabled for everyone though.

anionDev commented 3 years ago

Thank you for this information JohnMcPMS, sounds interesting!

JohnMcPMS commented 3 years ago

We should also use https://github.com/ronomon/pure to check for malicious archives. Depending on the performance, we could do it all of the time or only when the file came from an untrusted source / had a hash mismatch that was overridden.

farag2 commented 3 years ago

When can we expect the zip supported release?

denelon commented 3 years ago

@farag2 we haven't got a date for .zip yet. It looks like it will be post 1.0. We've got quite a few Issues with "label:Issue-Bug" to squash first. There has been interest from a community member to contribute to that feature, so it might get done before we would otherwise get to it. It is one of the top asks along with #182 .exe and #221 PowerShell cmdlets.