-
-
Notifications
You must be signed in to change notification settings - Fork 353
Default to zlib-rs and drop other options #1961
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Comments
Thanks for the nudge, I had it vaguely on my radar but wouldn't have acted on it timely. If you want your name on the first step towards that goal I will let you have it :) - otherwise I'd think I can get it done till the 22nd of April. |
PR written. :) |
joshtriplett
added a commit
to joshtriplett/gitoxide
that referenced
this issue
Apr 21, 2025
As of zlib-rs 0.5.0 (depended on by flate2 1.1.1), zlib-rs no longer exports C symbols by default, so it doesn't conflict with any other zlib that might be loaded into the address space. This removed the primary issue that made zlib selection a challenge that needed to be exposed to users: users may already have some other particular preference on zlib implementations, or want to use a system library, or want to ensure C dependencies use a particular zlib. Since zlib-rs 0.5.0 no longer conflicts with other zlib implementations, gix can make this choice independently and not create issues for the user. Given that, use zlib-rs by default, for performance out of the box with no C compiler requirement, and deprecate all the feature flags for other variations. A future major version bump can drop all of these features. This also means that (for instance) max-performance becomes the same as max-performance-safe, so such features are deprecated as well. Depend on flate2 with `default-features = false`, which brings us closer to eliminating the `miniz_oxide` dependency, which will improve build time for everyone. Currently, the `gix-archive` dependency on `zip` still activates the `zip/deflate` feature which enables `flate2/rust_backend`; this can be fixed to use `deflate-flate2` as soon as zip-rs/zip2#340 is fixed upstream. Fixes: GitoxideLabs#1961
joshtriplett
added a commit
to joshtriplett/gitoxide
that referenced
this issue
Apr 21, 2025
As of zlib-rs 0.5.0 (depended on by flate2 1.1.1), zlib-rs no longer exports C symbols by default, so it doesn't conflict with any other zlib that might be loaded into the address space. This removed the primary issue that made zlib selection a challenge that needed to be exposed to users: users may already have some other particular preference on zlib implementations, or want to use a system library, or want to ensure C dependencies use a particular zlib. Since zlib-rs 0.5.0 no longer conflicts with other zlib implementations, gix can make this choice independently and not create issues for the user. Given that, use zlib-rs by default, for performance out of the box with no C compiler requirement, and deprecate all the feature flags for other variations. A future major version bump can drop all of these features. This also means that (for instance) max-performance becomes the same as max-performance-safe, so such features are deprecated as well. Depend on flate2 with `default-features = false`, which brings us closer to eliminating the `miniz_oxide` dependency, which will improve build time for everyone. Currently, the `gix-archive` dependency on `zip` still activates the `zip/deflate` feature which enables `flate2/rust_backend`; this can be fixed to use `deflate-flate2` as soon as zip-rs/zip2#340 is fixed upstream. Fixes: GitoxideLabs#1961
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
As of zlib-rs 0.5.0 (depended on by flate2 1.1.1), zlib-rs no longer exports C symbols by default, so it doesn't conflict with any other zlib that might be loaded into the address space.
This removes the primary issue that makes zlib selection a challenge that needs to be exposed to users: users may already have some other particular preference on zlib implementations, or want to use a system library, or want to ensure C dependencies use a particular zlib. Since zlib-rs 0.5.0 no longer conflicts with other zlib implementations, gix can make this choice independently and not create issues for the user.
Given that, I think it may make sense to use zlib-rs by default, for performance out of the box with no C compiler requirement. It may also make sense to drop the other variations, for simplicity and reduction in support burden. Prior to the next major version bump, this could happen by preserving them as dummy features with e.g.
zlib-ng = []
and ignoring them, and at the next major version bump you could drop them entirely.This would also mean that
max-performance
becomes the same asmax-performance-safe
, allowing simplification and eventual elimination of those options as well. You'd no longer need to provide guidance that tells libraries to carefully not activate some features while telling end users to be sure to activate them for performance; gix could provide maximum performance out-of-the-box.Finally, this would mean that you could depend on flate2 with
default-features = false
, eliminating the miniz_oxide dependency. That would improve build time for everyone.The primary downside of this approach would be that you'd always build zlib-rs. However, because this approach eliminates the build time of miniz_oxide, I think on balance this will end up not being a problem for build time.
The text was updated successfully, but these errors were encountered: