-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Deprecate cargo macros #2840
Comments
I would agree but we use them in |
I'm more worried that because these aren't clap related, what if people want more cargo metadata exposed? These started as just I also agree they're pretty widely used which I think adds support to us taking it slow if we move forward (deprecate for a while, remove in a future major release), and also adds support to us creating the crate in our org with an identical API to make the transition painless. |
I can understand the desire to spin things off. I've wanted I agree that the right route forward is a crate we delegate to but still provide a convenience for clap users. |
Since a deprecation is not a breaking change, should we move this out of the 3.0 milestone? |
It is in 3.0 milestone similar to #2835 because we need to add deprecation warnings. |
We should not be deprecating anything without having a replacement to point people towards. Unless we are creating the crate now, we shouldn't do this. With #2835, we have replacements (builder, derive, from usage) that we can point people to as the recommended approach. |
Good point. My point was just to deprecate for 3.0 like @pksunkara mentioned, but you're correct we could deprecate anywhere in the 3.x lifetime. I'll place this at the 3.1 milestone as a placeholder for "decide on this sometime in 3.x" And of course we're not locked into spinning these out, I'm open to suggestions and opinions on the matter too. |
I think it'd be perfectly reasonable to just make these non-public before 3.0, as long as the top-level app_from_crate macro still exists. I don't think we have to provide a replacement first. These macros just existed to pass to the appropriate clap functions. |
For context, I'm recommending in #2617 that we provide built-in transition paths for users via deprecations to streamline the upgrade process. We can do breaking changes but ideally we have a deprecation windows first |
IIRC, people actually use those underlying macros directly instead of |
Random notes:
|
Maintainer's notes
Path forward
crate_*
macros, pointing people to that cratePlease complete the following tasks
Clap Version
3.0.0-beta.4
Describe your use case
I'm proposing removing the convenience macros for getting information from
cargo
at build time. Specifically:crate_license
crate_version
crate_authors
crate_description
crate_name
None of these utilize anything inside of
clap
and simply call out to checking environment variables thatcargo
populates at compile time.Describe the solution you'd like
These would be prime candidates for spinning off into a crate dedicated to such information about Cargo. I'd actually be kind of surprised if a crate with this functionality doesn't already exist. If one doesn't exist, I'm not against hosting one inside the clap-rs org, but being that it's not actually clap related this repository is probably a bad fit.
I propose we deprecate for v3, and remove for v4. That gives us time to either find a crate to suggest or pull these macros into one ourselves.
Alternatives, if applicable
Additional Context
I'm open to suggestions and thoughts on the matter.
The text was updated successfully, but these errors were encountered: