-
-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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_disable: support optional replacement parameter #18733
deprecate_disable: support optional replacement parameter #18733
Conversation
I'd suggesst this be an array in the API JSON, in case we want to add support for multiple replacements to the DSL. Maybe it should be called |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One style/prose nit and then should be good to 🚢!
I would very much like us to avoid specifying multiple replacements for a single formula (and therefore making this an array). It's much less useful to say "to replace this: go check out multiple other projects and decide" than "to replace this: we have decided X is the best option". |
8f7cb94
to
215fc85
Compare
Changed the replacement message to use a heredoc and reduced indentation to two spaces. Note that the heredoc adds a trailing newline compared to the previous inline string. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @alebcay!
brew style
with your changes locally?brew typecheck
with your changes locally?brew tests
with your changes locally?Addresses #18294.
A replacement may be specified like so:
which yields something like
and, for disabled:
which yields something like
brew install
help text. Note that there is no distinction between the string argument as a formula or cask; there is no validation on the value of the string.deprecate!
reason whendisable!
exists #18661 is open and this may need to be refactored after that is merged (or vice versa).