Skip to content

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

Closed
joshtriplett opened this issue Apr 20, 2025 · 2 comments · Fixed by #1963
Closed

Default to zlib-rs and drop other options #1961

joshtriplett opened this issue Apr 20, 2025 · 2 comments · Fixed by #1963
Labels
acknowledged an issue is accepted as shortcoming to be fixed help wanted Extra attention is needed

Comments

@joshtriplett
Copy link
Contributor

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 as max-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.

@Byron Byron added help wanted Extra attention is needed acknowledged an issue is accepted as shortcoming to be fixed labels Apr 20, 2025
@Byron
Copy link
Member

Byron commented Apr 20, 2025

Thanks for the nudge, I had it vaguely on my radar but wouldn't have acted on it timely.
Thus, I am happy to see this issue and the list of advantages, all of which make it a change to look forward to.

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.

@joshtriplett
Copy link
Contributor Author

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
@Byron Byron closed this as completed in 96164c5 Apr 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
acknowledged an issue is accepted as shortcoming to be fixed help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants