remove the prodash feature#2473
remove the prodash feature#2473Alexander Kjäll (alexanderkjall) wants to merge 1 commit intoGitoxideLabs:mainfrom
Conversation
As that feature is just from an optional dependency, I think a consumer of this crate should use the progress-tree feature
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 90cc5be06b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "Codex (@codex) review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "Codex (@codex) address that feedback".
| ## Re-export the progress tree root which allows to obtain progress from various functions which take `impl gix::Progress`. | ||
| ## Applications which want to display progress will probably need this implementation. | ||
| progress-tree = ["prodash/progress-tree"] | ||
| progress-tree = ["dep:prodash", "prodash?/progress-tree"] |
There was a problem hiding this comment.
prodash feature alias
If any downstream manifest still enables gix with features = ["prodash"] (or forwards gix/prodash transitively), this change makes Cargo fail during feature resolution: using dep:prodash removes the implicit public prodash feature entirely. I verified that the parent revision still exposed prodash => ["dep:prodash"], while the new manifest rejects that feature name, so this is a breaking change for existing consumers rather than just an internal cleanup.
Useful? React with 👍 / 👎.
|
This was intentionally changed from |
|
Thanks a lot for contributing Alexander Kjäll (@alexanderkjall) , and for chiming in Bennet Bleßmann (@Skgland). It seems there is a conflict of interest here, and I'd rather keep it like it is than to reintroduce another downstream issue - there is seemingly no way to fix both until the Thanks for your understanding. PS: If there is other options, please let me know in the comments. |
3 participants
As that feature is just from an optional dependency, I think a consumer of this crate should use the progress-tree feature?
from: https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/src/gix/debian/patches/reduce-features.patch?ref_type=heads#L26
author: Fabian-Gruenbichler