Option to have tool included in the package

[majkinetor]

We should have an option to make a package some type of container (like zip) that can include binary files.

On chocolatey coreteam repo we call this embedded packages. Prior to introducing them, 404 when installing a package was an everyday thing, you couldn't cache installers and versioning didn't work either because vendors would remove binary tool from upstream location. There was also a problem of silent update which invalidates a checksum which is not that infrequent at all and 100% solvable with embeding.

While this can not be done for 100% of packages due to a) distribution rights b) size, it still leaves a lot of space for good working packages. You can see on my bot report that majority of ~250 mainstream packages with millions of downloads are embeeded (they have 📥 icon next to the name). This proved to be great solution that you can rely on premise extensivelly where you can cache those packages via artifactory, nexus and friends, or anywhere - for example github releases from where people can install a package without even chocolatey working in the future.

This kind of package dominates nowdays, as more and more of them have permissive licence (either some open source licence or explicitelly allow for redistribution or are simply asked for permission).

[megamorf]

I believe this has been requested already, see #140.

[majkinetor]

That is unrelated.

[denelon]

This looks related to #340

[denelon]

There is also a scenario in #118 regarding running a tool over a set of packages in some local storage to generate manifests for an enterprise source.

[majkinetor]

This looks related to #340

Not that related - You can perfectly have such installation option without repository at all. For example chocolatey can install nuget pacakge from local or remote store without ever contacting its 'public gallery' being that nuget is just a zip file that can contain anything.

There is also a scenario in #118 regarding running a tool over a set of packages in some local storage to generate manifests for an enterprise source.

Not related to this issue.

[denelon]

WinGet uses manifests for describing metadata about packages. This request seems to indicate a desire to include the "installer" along with the manifest. Individuals and organizations can, however, stand up their own REST source and provide alternate locations for installers. WinGet download is one mechanism for sourcing these installers, but this does not imply or provide any assurance that the distribution of installers for applications is authorized.

[majkinetor]

Such decision means that winget will never become a viable CI/CD tool. If I have to rely on network conditions, availability of vendors locations etc. the entire system can be used only for non-developer scenarios as there is no guarantee (and there can't be one) that any kind of automated build will work in the future. You can't reasonably expect that all vendors will behave a good way. This means that winget target group are not developers but power home users. I am not even talking about long periods here - older versions of packages usually stop working in a year or so.

Chocolatey had it that way in the beginning, and it simply didn't work. They had to introduce private CDN for paying customers that would make older packages work for a longer time, as you would typically get 404 error without it, sooner or later. With it, if you request a package, and it has non-working link, it will get replaced in situ with a working CDN link.

Embedding tools into packages solved this issue. I have builds that work over a decade with 0 problems. Packages can even be cached locally, so even if choco goes out of business, build will work. This is currently not achievable with winget.

We know that reproducibility is the most important aspect of automation so I hope thus that you will reconsider this. There is no reason that GNU, MIT and alike licensed tools that explicitly support redistribution can not be added in the package.