Add ZIP to stdlib

[juancarlospaco]

Add back ZIP to stdlib.

Pure-Nim or impure, but still even impure is better than calling 7zip.exe via system shell or packing stuff using staticRead.

Can be adding some nimble package to stdlib, or a new one, or an impure like C wrapper, etc.

Can help improve http of stdlib, installer/setup related stuff, is used on a lot of formats, and more.

API can be basic, at least to compress / decompress.

[disruptek]

What's wrong with https://github.com/guzba/zippy?

[c-blake]

As limited as "deflate" is (e.g., Zstd is much better), I'd say including zippy (the pure-Nim fork of @juancarlospaco's or) in the stdlib might add more value than many things already there. This runs head first into how to evolve the stdlib questions, which I think landed on "just grow the stdlib".

[disruptek]

If you put zippy in the stdlib, you've turned one problem into two problems.

Deprecate the nim-lang/zip and point people to zippy. Now there's no problem.

[c-blake]

Sounds like two problems to me either way 😄. "Package manager people" often over-discount the extra burden for other people of outside the stdlib stuff. And yeah people can also still not know it's in the stdlib, but many stdlibs have it at least in wrapper-of-zlib form. And @Araq was mentioning having stdlib depend upon it for more complete HTTP support. And we are still figuring out how to have stdlib/compiler depend upon 3rd party packages. So, anyway, like I said - "head first into how to evolve the stdlib" upon which reasonable people have disagreed and changed their minds over the years. 😄

[disruptek]

Deprecate the nim-lang/zip and point people to zippy.

This forwards everyone's goals without regard to the evolution of the stdlib. What comes next can be bikeshed by the naysayers.

[c-blake]

I love the positivity, but I also don't see how it moves forward portable support for Content-encoding: gzip in stdlib HTTP until stdlib can depend on a 3rd party package. (Unless forcing resolution of such dependency sooner rather than later is a +.)

[disruptek]

If you're not for deprecating nim-lang/zip, then you're against it. Why?

[c-blake]

I am for the portable (as in no external zlib required) support for Content-encoding: gzip which to me means either zippy in the stdlib or stdlib depending on external stuff.

[c-blake]

(I guess I should say that I have not reviewed zippy for CPU/OS portability, but it seems at least do-able in theory and is currently a very small module.)

[juancarlospaco]

I did not say something is wrong with anything, I say we are calling 7zip.exe via system shell to unzip stuff. :neutral_face:

That promise that useful stuff will be added to the stdlib never fulfilled the objective, with or without Fusion. :cry:

New users often choose D lang for the useful rich stdlib, but Nim struggles for years to add basic stuff to stdlib.

[mratsim]

I did not say something is wrong with anything, I say we are calling 7zip.exe via system shell to unzip stuff. neutral_face

That's a significant security risk.

[juancarlospaco]

Yes, I think that can be improved; Would be useful for basic HTTP compression support.

[juancarlospaco]

DocGen can generate Ebook documentation without changes to the docgen code, because epub is just HTML/CSS in a ZIP, docgen already does HTML/CSS. :thinking:

[ringabout]

Related feature request: asynchttpserver: https://github.com/nim-lang/Nim/issues/9175 httpclient: https://github.com/nim-lang/Nim/issues/7864

[c-blake]

Related Forum thread.

[arnetheduck]

gzip in stdlib HTTP until stdlib can depend on a 3rd party package.

This actually has a trivial solution: move the http support to a library which can depend on gzip (and release gzip support separately from a nim release, at its own leisure).

An example can be found in nim-websock which adds compression / deflate to websockets without any further library additions.

[Araq]

The correct solution is indeed to move the HTTP stuff out of the stdlib so that it can evolve much more easily.