Higher limit for package size

[majkinetor]

I think 200MB limit is too small in current day and age. It was introduced years ago and there was that gallery bug also with larger packages.

So

1. Years passed, so size should go up because in Electron age, todo apps can have 100MB+
2. Packages with multiple arch are particularly problematic as limit is shared among them.
3. Workaround for single arch fitting in is workable although not nice, for multi-arch is highly problematic because it boils down to multiple packages or non-embedded packages (which are next to junk for me at least and I don't use them except for few tools like browsers)
4. The gallery bug is fixed

I think around 500MB would be good next limit, but even smaller changes would be beneficial, but not bellow 350MB IMO. Ideally 1 GB value would be nice for foreseeable future.

Originally posted by @majkinetor in #48 (comment)

[TheCakeIsNaOH]

I absolutely agree.
Embedded packages are vastly better when it is possible to embed the binaries.

There are a list of packages which I use that would be embeddable if the file size limit was larger.

[chitrarthSahai]

Hi,

Is there any package size limit to host packages in our internal feed as well?? What if the application I want to deploy is over a GB?

[TheCakeIsNaOH]

@chitrarthSahai There is not a limit built into choco.exe that I am aware of.

Currently, choco cannot hash the .nupkg on install if it is over 2gb in size, but that issue produces a warning, not an error. See chocolatey/choco#747 for more information and to track the issue.

There is likely a limit built into your internal feed. but that depends on what software you are using to host your feed and how it is configured. For example, most reverse proxies have a configuration option to limit the max upload and download sizes, which would put a limit on the size of a package. Or a limit may be built into the software providing your feed.

In terms of what is practical however, I would generally suggest limiting your package sizes to about 1.5gb. Anything larger, and it can start to get a bit unreliable in my experience during the download of the package, and extracting the package take longer, and it can start to use up significant disk space.

To get around this, I would suggest downloading large installers and other binaries from other internal sources. SMB share, S3, Wasabi, other private HTTP server, etc. Anything that would make the package over 1.5-2gb

[bdukes]

I've just run into this with the imagemagick.tool package (see Discord discussion)

[pauby]

While I know this question has come up a few times, it's not quite as simple to resolve as it may seem. This is something that the Chocolatey Team have regularly spoken about, but it's not something that has been possible to progress. But it is something we know is needed, and it is not something we have forgotten about.

Having said that, to manage expectations, this is unlikely to be resolved in the near future.

[kirkpabk]

The size limits appear to really be arbitrary based on repositories and hosting support.

https://learn.microsoft.com/en-us/azure/devops/artifacts/reference/limits?view=azure-devops

Azure has universal packages supporting a 4T range...

In my humble opinion, the size limits should be recommended (defaulted) by chocolatey, but configurable. Wherein support on chocolatey repositories may be enforced at that level--throwing exceptions if package exceeded supported limit. Allowing corporate hosted and internal repositories to expand those limits as per their requirements.

This increases flexibility while still supporting other distribution methods for larger artifacts.

[pauby]

@kirkpabk This discussion is around the Chocolatey Community Repository limits for packages and is related to the size that can be submitted to VirusTotal. Those limits do not affect corporate hosted and internal repositories or any other repository.

Allowing corporate hosted and internal repositories to expand those limits as per their requirements.

The size of a package in hosted repositories is limited by Chocolatey CLI's ability to checksum the package contents and the repository manager size limits. Just to be clear, this discussion is not around that.

[TheCakeIsNaOH]

@kirkpabk the 200mb limit is only in reference to the Chocolatey Community Repository, and is applied server-side.

I have many packages larger than 200mb on my internal Nexus server, going up all the way to a bit over a gigabyte. As far as I am aware, there is no explicit limit on package sizes within the current version of Chocolatey CLI. However, due to the way Chocolatey installs packages, I would suggest about 2gb to be the max size, and for anything over that have the binaries be downloaded during the chocolateyInstall.ps1.

[kirkpabk]

Nice, that's reassuring. Thanks.

…

On Sat, Dec 17, 2022, 3:10 PM TheCakeIsNaOH ***@***.***> wrote: @kirkpabk <https://github.com/kirkpabk> the 200mb limit is only in reference to the Chocolatey Community Repository, and is applied server-side. I have many packages larger than 200mb on my internal Nexus server, going up all the way to a bit over a gigabyte. As far as I am aware, there is no explicit limit on package sizes within the current version of Chocolatey CLI. However, due to the way Chocolatey installs packages, I would suggest about 2gb to be the max size, and for anything over that have the binaries be downloaded during the chocolateyInstall.ps1. — Reply to this email directly, view it on GitHub <#163 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABORF4ABLRH2GU5T6KRIML3WNYM3PANCNFSM6AAAAAATCDOGII> . You are receiving this because you were mentioned.Message ID: ***@***.***>