gitoxide requires miniz_oxide even when building with libz-ng

[joshtriplett]

Even when building with libz-ng, gitoxide still has miniz_oxide in its dependency tree (by way of flate2), and cargo ends up having to compile it. This is visible via cargo tree and the build logs from cargo.

This may be difficult to fix, as it's not trivial to say "use this only if that isn't set". But it'd be worth attempting to fix somehow, to eliminate the dependency and its compilation time.

[Byron]

Thanks for bringing this up!

I vaguely remember thinking that flate2 is built so that the default backend can be activated (and therefore will be built) even while additional backends are selected, like zlib-ng. This is helpful as it adds flexibility, but leads to overhead.

I wish that one day there is tooling that helps to manage and maintain the nightmarish complexity of all the features in this project, even though I have little hope 😅.

[joshtriplett]

@Byron It's possible to build flate2 and libz-sys without the default backends. The problem is, it's difficult to expose that via gix features in a way that doesn't have the same feature structure the underlying crates do: a pair of features such that if you don't enable either you get a build error. Ideally you'd be able to say "if X is enabled, Y should be disabled", but that's not possible with cargo features.

[NobodyXu]

Ideally you'd be able to say "if X is enabled, Y should be disabled", but that's not possible with cargo features.

More like cargo needs sum-type/enum in the feature system:

[features."flate-backend"]
choices = ["minoz", "libz", "libz-ng"]

[weihanglo]

Another way to manage this is to have all dependencies specified under workspace.dependencies with default-features = false, so we'll have a (slightly) better view when a feature is really needed.