Building with `--features=gix-features/zlib-stock` still pulls in `libz-ng-sys` about gitoxide

[carlocab]

One workaround is to do

cargo install --no-default-features --features=gix-features/zlib-stock

but it's not clear at all how much this disables relative to the default configuration. Ideally it should be simple to choose features so that they are identical to the default max configuration except for the zlib-ng backend.

Another workaround is to replace zlib-ng in this line

gitoxide/gix/Cargo.toml

Line 107 in d67551d

max-performance = [ "max-performance-safe", "gix-features/zlib-ng", "fast-sha1" ]

with zlib-stock, which results in the desired behaviour from

cargo install --features=gix-features/zlib-stock

However, it would be nice to not have to hack up a Cargo.toml here.

For reference, this is related to Homebrew/homebrew-core#129719, where we're trying to package gitoxide for Homebrew.

[Byron]

My only other request is for you to avoid changing these flags in future releases.

I will do my best to keep them those working and won't change them lightheartedly. Fortunately it seems like these flags are stabilizing, especially after the recent push, as they seem to now fit their purpose pretty well.

Besides that, it's exciting to see gitoxide on homebrew, thanks for all your work :).

[Byron]

Thank you so much for reporting this and most importantly, provide a workaround. What's astonishing here is that I was not aware that it's possible to specify any features that are defined in dependencies of the crate. This makes cargo features so much more powerful!

With that said, the way features are currently organized it's hard to reproduce exactly what the default is, minus zlib-ng, + zlib-stock, but being able to specify it from the command-line might be a game-changer for future iterations of how features are exposed by the crate.

As for the actual issue described here, there is nothing that can be done as cargo features are additive, and the default choice happens to optimize for performance. However, I think it could make a safer choice, as to not choose anything people usually want to override. Thus a better choice might be something like max-pure and then build on top of that. Thinking about it, I don't see a way yet to make it usable by everyone, it's really just about trying to find a local minimum that serves most.

Maybe for now, you can maintain a patch file to make the changes directly where you need them? cargo build --features=gix-features/zlib-stock isn't recommended for the reasons you mention, it's unclear what you get and I don't see a way to fix that.

I will think about better ways to organize features, but can't know for sure I will manage to make significant improvements.

[Byron]

In the linked PR (and soon in main) you find the improvements needed more more easily build something like max but with difference choices for zlib or hashing. Please let me know if this works for you. Please find attached the rendered docs, those will be up on docs.rs when there is a new gitoxide release.

gitoxide - Rust.pdf - jump right to the Package Maintainers section.

Thank you

[carlocab]

This works great, thanks!

❯ cargo tree --no-default-features --features=max-control,gix-features/zlib-stock,gitoxide-core-blocking-client,http-client-curl | rg libz
│   │   │   │   │   │   ├── libz-sys v1.1.8
│   │   │   │   │   │   └── libz-sys v1.1.8 (*)

Will this be in your next release?

[Byron]

Yes, it will be, and I think it's worth waiting as it will contain gix status or something like it.

[carlocab]

What's astonishing here is that I was not aware that it's possible to specify any features that are defined in dependencies of the crate.

Yes, the --features flag of cargo is woefully underdocumented. The gix-features/zlib-stock syntax is mentioned here, but I don't think it really gives you a clear idea of how it works.

Yes, it will be, and I think it's worth waiting as it will contain gix status or something like it.

Great, thanks!

My only other request is for you to avoid changing these flags in future releases. We only have a small team of maintainers at Homebrew for ~6000 packages, so we rarely have the time to check updates carefully for changes to the build configuration. We often only notice that configurations need to change when packages fail loudly while building.