Support installing .zip files about winget-cli HOT 161 CLOSED

This would enable Winget to support all the Sysinternals tools.

from winget-cli.

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

from winget-cli.

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

from winget-cli.

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)

from winget-cli.

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.

from winget-cli.

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.

from winget-cli.

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.

from winget-cli.

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.

from winget-cli.

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

from winget-cli.

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

from winget-cli.

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

from winget-cli.

I didn't mean to close the issue. I hit the wrong button when UI jumped on me.

from winget-cli.

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.

from winget-cli.

Are there plans to create a PR for the ZIP support any time soon? I do not see any technical requirement draft anywhere.
If no one is currently working on it then I will be happy to start with a draft proposal on how I imagine WinGet could support compressed archives.

from winget-cli.

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.

from winget-cli.

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

from winget-cli.

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.

from winget-cli.

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.

from winget-cli.

@Xeeynamo we're still catching up from the recent release activity and holiday. I'll see how soon I can pull a draft together for what we're thinking.

Hi Denelon 👋thanks for the quick reply.

I have been thinking on how installing compressed archives (eg. ZIP) would work. Allow me to share my thoughts.

The archive content is unpredictable

It can contains (but not limited to) one of the following options:

1. A stand-alone application. A single executable that is ready to be launched without performing any configuration (eg. installer).

2. Multiple applications. This is true for archives such as Sysinternals Suite, found on MS Docs.

3. An installer. If I recall correctly, downloadable Adobe products are a ZIP archive that contains an executable to run the installer. The installer itself can be an EXE, MSI or even a PS1 script.

As we already have a bunch of different scenarios, I would just focus on the first two as they might be the simplest implementation for a MVP:

Make it User or Globally accessible

We want to have an output directory to extract our application(s) to. Based on a flag in the YML we might specify if it should be extracted in %LOCALAPPDATA% or, ideally, %PROGRAMDATA% based if we want to make the application globally available. It can be a string that can have either user or global as values.

In-place upgrade?

We can easily agree that the output directory can be something like %PROGRAMDATA%\publisher\package, but this means that upgrades of the same application need to be in-place. This can lead to problems when a new version of the application removes a dependant file that was previously available, but the in-place upgrade would rather accumulate. Applications that rely on loading DLLs dynamically are affected by this problem.

An idea would be to clean-up the folder before performing the upgrade or just extract to %PROGRAMDATA%\publisher\package\version. This can be only done if we assume that the application would store the configuration in a different folder (eg. %APPDATA%), but as some applications store their configuration in the same extracted folder then it is easy to see how this cannot be viable.

There is also the problem of handling correctly the replacement or deletion of previous files if they are in use. Would winget just fail? What about rolling back the upgrade if it failed?

I could not find a way to solve this scenario yet and I do not believe that tracking the list of extracted files might be a clean solution either.

Give an easily reachable entry-point

An installer could generate a desktop icon or a Start menu entry, but not an extracted archive. A quick win would be to have a list of paths where each one is a local path to the executable we want to add, as a shortcut, to the Start menu or the Desktop. There might also be the need to customise the icon the shortcut is going to use.

A rough example

By collecting all my ideas, doubts and concerns I listed above, what I've been imaging could be an ideal YAML object is the following:

Installers:
  - InstallerUrl: ""
    InstallerSha256: ""
    InstallerType: "zip"
    Scope: "user"
    Shortcuts:
      - Path: "procexp64.exe"
        Icon: "procexp64.exe,0"
        Startmenu: true
        Desktop: false

I know I am over-simplifying some other very specific scenario and that I might've been overlooking some critical aspects of this specific complex problem, but I hope this will bring some value to the issue to collectively reach a good draft for an MVP.
I hope I have not been too intrusive with my thoughts 🙏.

from winget-cli.

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

from winget-cli.

This is terrible. WinGet is seriously crippled without this, and getting this in an update really soon should be a priority. So many apps would really greatly benefit from WinGet distribution, but literally just can't even submit a package because of this one issue. Have had to literally just revert to community packages on Chocolatey, which are almost always out of date or doing some processing for days after release so for any zipped app I care about I just have to manage manually. Quite unfortunate and annoying.

from winget-cli.

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

from winget-cli.

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

from winget-cli.

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

from winget-cli.

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.

from winget-cli.

@motevets - do you have any existing work on this?
@denelon - I'd be interested to contribute as well.

IMHO, having the ability to support .zip files opens the possibilities of letting developers install multiple versions of the same package, and switch when required.

# If first version of this package, set the PATH
winget install Oracle.OpenJDK -v 16

# Second version of same page. Probably prompt to use this as default?
winget install Oracle.OpenJDK -v 15

# Set the version for this shell
winget use Oracle.OpenJDK -v 15

# Set the default for all shells henceforth
winget default Oracle.OpenJDK -v 15

from winget-cli.

related to microsoft/winget-pkgs#580

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

from winget-cli.

@c16a I'd be happy to discuss this with you. I'd expect @JohnMcPMS would also be interested. We did get the opportunity to meet with @motevets as well. Feel free to send an e-mail so we can try to coordinate a good time to chat. @brunoborges might also be interested with your use case for Java.

from winget-cli.

@denelon @brunoborges - I've written to you separately.

For everyone else, the following are the items that are being considered

1. Use a path (like %USERPROFILE%/WinGetApps) as a package tree for all binary downloads.

No not %USERPROFILE% please, it's drive cannot be changed.
The C:\ drive is already much bloated with non-system related stuff.
Use %HOMEDRIVE%%HOMEPATH% instead which can be pointed to a different drive/folder.
Much better is to make such default location configurable per system and per user.

from winget-cli.

What about extending the installer manifest (or having a zip manifest) that is added to the repository and contains this information?

from winget-cli.

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:

• Gitlab-runner - I implemented service option, autologon option and installdir, since for some of them u need external tools which is easy for package to depend on but may be hard for you to do manually.
• Rundeck - I implemented 10 options everybody needs but they really didn't want to put in an easy to use installer for some reason.
• Signal - I added options people need but were not implemented upstream without finding specific issues on the pile (package installs oposite of those options by default, as that is what was asked by everbody)

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.

from winget-cli.

@denelon @brunoborges - I've written to you separately.

For everyone else, the following are the items that are being considered

1. Use a path (like %USERPROFILE%/WinGetApps) as a package tree for all binary downloads.
2. Supporting installation via .zip files
   a. Downloading files with checksum support.
   b. PowerShell scripts to process and add this to system PATH.
3. Supporting installation of multiple versions of the same package
   a. Setting default versions across shells, and per-shell versions.

Of course, open to other suggestions in this area.

from winget-cli.

That would only work for statically linked apps (like Go apps) with no other assets and not for dynamically linked apps like QOwnNotes (with all the Qt DLLs).

from winget-cli.

Surely other archive files such as tar should be allowed. Also, the supported methods of compression should be stated, or else no methods of compression should be allowed, else .zip, .tar, .zip.xz and .tar.gz (etcetera) shall also be vying for support.

from winget-cli.

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.

from winget-cli.

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:

microsoft/winget-pkgs#1288

from winget-cli.

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.

from winget-cli.

When can we expect the zip supported release?

from winget-cli.

What if the archive cannot be extracted by the Expand-Archive cmdlet (like GZ archives)? Supporting other archive formats currently requires another cmdlet to be installed, which is currently being worked on #163

To be honest, I assumed that archive & extraction support would be baked into WinGet itself as part of this. By extension, it'd become WinGet's responsibility to include support for a reasonable set of archive formats (.zip, .7z, .tar, .gz).

Some of them have top level directories, and some don't.

With other managers, you'd just define this as part of the manifest. As well as defining where binaries (what dir/files to add to path)

Def agree that checksums are 100% required.

Sorry for the Linux-speak, but like strace at process level. I'm assuming the PowerShell script would be run as a child process of the CLI, so we could monitor all file system calls that it makes. This can be used during integration testing. If Windows lets us monitor and block all file system calls made by the current or child thread that don't pass some criteria, then the CLI can use this as an additional layer of security during installation as well.

I know the capability to record PS calls exists (Transcripts) and I believe there's a way to lock down what CMDlets you can call, but I don't know about locking down FS calls specifically without getting knee deep in NTFS ACLs.

from winget-cli.

@Xeeynamo I wonder if there is a case to simplify the process of taking one of these .zip package and building an MSIX to handle the other concerns? (Longer term possibility)

In the short term, feel free to build a draft PR for a spec. You can see we have a spec for the Dependency feature, and it is being broken down into bite sized parts for implementation. I would expect to follow a similar approach here so we can articulate what is proposed and gradually complete the implementation.

We would certainly want to start off with a Feature Toggle for .zip as an experimental feature. We would need to iterate on what the schema might look like and work through the right way for a .zip enabled client to handle this "new" manifest schema. Initially, we would only support "local" manifests with winget install <package> -m <pathToManifest> until we had a very solid set of capabilities.

Making schema changes must cascade across the entire product ecosystem:

• Client
• Validation Pipelines
• Publishing Pipelines
• REST API
• wingetcreate

from winget-cli.

Here to request this and the fonts to be put in the 1.3 milestones.

from winget-cli.

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.

from winget-cli.

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.

from winget-cli.

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?

from winget-cli.

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.

from winget-cli.

@doctordns we have quite a few bugs to squash in the near term.

We are tracking .zip #140 and portable applications #182 as top 5 in the backlog (along with native PowerShell #221 support) for new features on the client. I just don't yet know what the sequencing is going to be for all of them yet. We've been discussing whether to try and build an entry in Apps and Features so we can track "upgrade" and "remove" scenarios. Sadly there are a large number of edge cases to deal with.

from winget-cli.

Let's just never support software that doesn't provide MSI packages then. Windows being 20+ years late on the package manager issue, lots of software didn't bother with offering MSI in their release pipeline, and that won't change anytime soon.

So if you want a mildly useful package manager, it will need to "support any compressed file without following a spec", probably by analyzing the structure of what's inside, rearranging it automatically according to a spec, and installing it. In a way, it's almost a conversion from .zip to MSI.

Or we could just unzip it at an arbitrary path, but that's not really managing the package.

from winget-cli.

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?

from winget-cli.

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.

from winget-cli.

there are several comments in this thread already with design suggestions for that like #140 (comment)

from winget-cli.

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.
malxau/yori#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
#361
The aim should be portable apps support of the same level as Scoop.

from winget-cli.

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

from winget-cli.

Would it be feasible/reasonable to effectively take zips and then repackage them into msix/msixbundles using app execution aliases? It'd probably be heavy and have some catches I'm not thinking of, but would bring along the implicit benefits of msix and solve the shim issue (though that functionality is not without it's own issues).

from winget-cli.

I'm positive that it's straight forward for single file execs, but shell transformations might be required with zip extracts (stripping top level directories, renaming etc). Nevertheless, I get your point: when we speak about supported package types, zip and exe (say) could be treated separately.

Yup. My biggest concern to add is just security/environment restrictions on running scripts. So ideally from both maintenance perspective and a security perspective, these common cases case work with some configuration and no script/shell involved unless absolutely necessary.

from winget-cli.

Yes, you're rightfully paranoid. Tools like kubectl, and terraform can straight up be moved into the install location in their own directories.

Here's my take on archives.

Problems

1. What if the archive cannot be extracted by the Expand-Archive cmdlet (like GZ archives)? Supporting other archive formats currently requires another cmdlet to be installed, which is currently being worked on #163
2. Some of them have top level directories, and some don't.

Possible Solutions

Checksums

For the archive, and the PowerShell script (if any)

Ensuring unauthorized file system access

We need to ensure that the above PS script does not make any file system changes beyond the scope of the installed directory for this version. Besides manual review, the only secure alternative that comes to mind is if the winget-cli has auditing control of the files being access by the Powershell script itself.

Sorry for the Linux-speak, but like strace at process level. I'm assuming the PowerShell script would be run as a child process of the CLI, so we could monitor all file system calls that it makes. This can be used during integration testing. If Windows lets us monitor and block all file system calls made by the current or child thread that don't pass some criteria, then the CLI can use this as an additional layer of security during installation as well.

Thoughts?

from winget-cli.

Hi @c16a,

I wanted to reply to your example regarding OpenJDK (Java). Today, the OpenJDK project is implemented in a way that it is smart enough to find where the JDK is installed. The binaries (e.g., java, javac, jar, and others) know where they are installed and can find the other files of the JDK. Simply put, the user only needs to point JAVA_HOME to a different JDK installation, and ensure %JAVA_HOME%/bin is part of %PATH%.

As you may know, Linux package managers don't implement the idea of 'switch/use/default'. This concept is always implemented by a different tool, designed oftentimes, for specific technologies. In Ubuntu/Debian, there is an update-java-alternatives command. In CentOS, there is an update-alternative command, and it is unclear if it supports JDK installations adequately.

In the Java world, there are better tools designed specifically to manage multiple JDKs installed in a local environment. I wrote about that in this article.

All said I am not very much in favor of winget having such functionality, at the very least for managing JDKs, because on Windows, JDKs may be installed with MSI or simply have ZIP files extracted into somewhere. And different MSI installers for JDKs may have different settings/defaults, and I am certainly not in favor of winget forcing MSI or ZIP files for JDKs to conform to some standard. I think this would increase the scope of winget too much, and complicate things rather than simplify.

m2c

from winget-cli.

This would be great to install packages like the Hugo static site generator too. It is a super simple case because it is a single executable, distributed in a zip file and just needs to be on the path.

from winget-cli.

We still plan to build support for .zip, but we have some other changes coming in the v1.1 manifest schema to support the more complex behaviors associated with "installing" a file downloaded as a .zip.

Thank you, @denelon.
What's about self extracting exe files? Are they also not supported for the same reasons?

from winget-cli.

Too bad for apps like https://github.com/pbek/QOwnNotes that don't require installation. 😅

from winget-cli.

I would hope that the ability to handle zip files would get added at some future point. Is this feature request reflected in the road map ( I can't find it)? It should be.

from winget-cli.

We've been discussing whether to try and build an entry in Apps and Features so we can track "upgrade" and "remove" scenarios.

What about naming the ARP key Winget_%appname%? On upgrade you simply update the DisplayName value inside this key. UninstallString would be something like winget.exe --uninstallzip %appname% and the InstallLocation value points to where the .zip was extracted.

from winget-cli.

Technically, deb and rpm packages are archives (for deb, tar, and for rpm, cpio, both then gziped not zip) and the simplest installation just extracts the files to the locations specified by full paths or metadata. Most existing zip files couldn't be installed that way, but it is technically correct. The equivalent could be added to the manifest along with the zip file.

Technically, deb and rpm are similar to msi.

Both DEB and RPM come with a spec just like MSI also has a spec. Of course all of them are compressed files.

But "supporting ZIP" would mean "supporting any compressed file without following a spec".

-- edit --

And the moment someone suggests a spec, a directory structure and some standardization of files, booom. You've got MSI.

from winget-cli.

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

from winget-cli.

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.

from winget-cli.

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.

from winget-cli.

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

from winget-cli.

Yeah, I'd be interested in contributing. 😄

from winget-cli.

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.

from winget-cli.

@RichiCoder1 several packages have explicit distribution and licensing concerns that prevent us from automatically converting or modifying or distributing their software. We're looking at ways we can provide support publishers with respect to packaging their software installers via MSIX.

from winget-cli.

It'd be nice to support a System VS User-like switch here where you could either install to a well-known UserProfile directory or a well-known OS drive-level directory.

Yep, thanks for this. Might make sense for enterprise deployments too.

It would be really nice if PowerShell support was only necessary for complex edge-cases and simple zips/single file exes that are just xcopy & add to Path "Just Work".

I'm positive that it's straight forward for single file execs, but shell transformations might be required with zip extracts (stripping top level directories, renaming etc). Nevertheless, I get your point: when we speak about supported package types, zip and exe (say) could be treated separately.

from winget-cli.

Thanks a lot for the inputs @RichiCoder1. I'll discuss them with the others and post timely updates.

from winget-cli.

What does it mean "install the program" once it is extracted from the ZIP file though?

I don't see neither yum or apt supporting installation of ZIP.

Technically, deb and rpm packages are archives (for deb, tar, and for rpm, cpio, both then gziped not zip) and the simplest installation just extracts the files to the locations specified by full paths or metadata. Most existing zip files couldn't be installed that way, but it is technically correct. The equivalent could be added to the manifest along with the zip file.

from winget-cli.

"just analyzing" certainly isn't simple, especially considering 20+ years of software that never bothered to produce MSI packages :-D

from winget-cli.

Around 50% of what it needs zip support for is to extract an installer and run it, worrying about portable programs without a standard-following installer or anything should probably come after that

from winget-cli.

With the recent changes in the 1.1 schema, we would be able to specify that a .zip contains an installer. The Apps and Features section could identify an installer contained within a .zip file.

from winget-cli.

Seems to me that a zip file could contain at least two different things:

• the app itself - winget needs to extract it to some folder, and optionally create a shorcut to the main app.
• an app installer application - winget needs to run extract the contents, then run the identified exe to do the installation.

Can the schema support both?

from winget-cli.

Why not have the repository handle the extraction?

from winget-cli.

microsoft/winget-pkgs#174

from winget-cli.

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.

from winget-cli.

@tap52384 😲

from winget-cli.

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

from winget-cli.

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?

from winget-cli.

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

from winget-cli.

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.

from winget-cli.

Thank you for this information JohnMcPMS, sounds interesting!

from winget-cli.

@c16a that all sounds awesome! Immediate feedback would be:

Use a path (like %USERPROFILE%/WinGetApps) as a package tree for all binary downloads.

It'd be nice to support a System VS User-like switch here where you could either install to a well-known UserProfile directory or a well-known OS drive-level directory.

PowerShell scripts to process and add this to system PATH.

It would be really nice if PowerShell support was only necessary for complex edge-cases and simple zips/single file exes that are just xcopy & add to Path "Just Work".

from winget-cli.

Just to support this suggestion:

This would make installing PowerShell 7 on Windows ARM64 much much easier 👍

from winget-cli.

@Xeeynamo we're still catching up from the recent release activity and holiday. I'll see how soon I can pull a draft together for what we're thinking.

from winget-cli.

I wonder why zip is already used in this testdata.

from winget-cli.

@pbek We were expecting it to be a supported type very early on. Unfortunately, we had to adjust our expectations as we continued building the core functionality for 1.0. The service side took quite a bit more than estimated, and our current focus is stability, catalog health, and UX. We still plan to build support for .zip, but we have some other changes coming in the v1.1 manifest schema to support the more complex behaviors associated with "installing" a file downloaded as a .zip.

from winget-cli.

@pbek, yes. It's likely we will have a similar implementation for both new types. We are considering building entries for them in Apps and Features so they can also be upgraded and installed. Ideally, publishers would build their own installers to handle these cases, but we wanted to make sure the other core functionality would work in either case. Sometimes a simple .exe will get the job done, but it's not really conducive to a package manager looking to manage software on a Windows system.

from winget-cli.

I think those could be supported. If we declare them as a portable/standalone .exe inside of a .zip, we would still capture the "version" and use the other metadata to create the appropriate entries in the system, add the proper PATH entry and it would be usable. Some of the work we're doing now for the 1.1 schema will make scenarios like this possible in the future.

from winget-cli.

Thanks

from winget-cli.

probably a dumb question but why not use an external c++ library? I'm not a c++ dev but I would assume that they exist

from winget-cli.

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?

I would want WinGet to automatically unzip the folder and install the program

from winget-cli.

What does it mean "install the program" once it is extracted from the ZIP file though?

I don't see neither yum or apt supporting installation of ZIP.

from winget-cli.

from winget-cli.

So where goes the directory structure definition? Should all ZIP files follow the same structure?

from winget-cli.

Yeah I think it's a really hard task (to do correctly), but I also think if winget doesn't provide a solution, it won't really be that useful.

from winget-cli.

Should all ZIP files follow the same structure?

This is never going to happen. The manifest would have to specify which file in the zip is the main executable, eg ZipApp: bin/foo.exe. WinGet can then add it to %path% or create a start menu shortcut.

from winget-cli.