-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
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
Add HOMEBREW_UPGRADE_GREEDY="auto-updates" and "latest" #16736
Conversation
bb30264
to
178699c
Compare
--greedy*
options in HOMEBREW_CASK_OPTS178699c
to
a78094b
Compare
a78094b
to
821fe73
Compare
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.
This should also be supported in brew outdated
, which also has these options.
821fe73
to
112e4d9
Compare
112e4d9
to
0a85df8
Compare
Added in latest update. |
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 of the PR!
Sorry to contradict later in the day: I think this would be nicer as three separate variables instead.
@reitermarkus If you disagree: let's discuss here instead. |
As I mentioned in the issue, I prefer one variable since it avoids the case where multiple can be specified. For the user it's a choice between |
@reitermarkus Feels a bit weird to have |
FWIW, the existing code does handle when multiple options are specified (e.g. brew/Library/Homebrew/cask/upgrade.rb Lines 79 to 90 in 7848bd3
If separate env vars are preferred I have a patch ready to go for that too (https://github.com/jck112/Homebrew-brew/commit/ea119ed07f3d943d0bb3fdf2f0f7b0c150f77a33). |
Thanks @jck112! Will let you know when we've decided. @Homebrew/maintainers @Homebrew/cask any thoughts on one variable vs. many? We don't have many variables which have differing behaviours due to setting the same variable to different values so feels unintuitive but I'm open to other viewpoints. |
I would prefer just one variable :) |
My general opinion (to anything):
|
We can call it
That's because we also don't have that many flags that have the same prefix with different behaviours like The one I could find is |
That's actually a good question. I don't think it is well defined and more of an implementation detail. |
Yeah, it is. I think following the flags and having three variables makes sense to me. |
Okay, if it wasn't, separate variables would make sense to me. Given that it is equivalent, one variable makes more sense to me. |
Personally, I think it would actually make more sense for the flags to be |
I recall we passed on this in #15164, but I'm glad this is discussed. Regardless, I agree with the 3 variable approach if we are keeping the flags as they are.
I like this approach a lot more, with the one caveat that |
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.
Ok, I'm convinced by this approach, thanks everyone and @jck112 again for the PR.
I've left one comment already but also:
Personally, I think it would actually make more sense for the flags to be --greedy, --greedy latest and --greedy auto-updates so only one option can be specified. For now, they should at least have conflicts with each other.
I strongly agree with this if we merge this PR. Not saying the values should necessarily be latest
and auto-updates
but whatever values we use should be consistent between there and here and we should fail on unknown other values.
This may require some deprecation cycles in later releases.
@jck112 if any of the above is confusing to you: my bad, sorry, ask whatever questions you need. Thanks again ❤️
ENV["HOMEBREW_UPGRADE_GREEDY"].present? && | ||
!cask_upgrade_greedy_latest? && | ||
!cask_upgrade_greedy_auto_updates? |
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.
Feels a little weird/loose for "any value except latest
or auto-updates
implies greedy". Maybe we should only allow this value to be set to 1
or greedy
or some few known values and error out otherwise?
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.
Previously HOMEBREW_UPGRADE_GREEDY
was a Boolean so accepting any value is to maintain compatibility with any existing value a user may have set (e.g. "1", "true", "yes", etc).
However I agree that it would be nicer to accept specific values (e.g. "all", "latest", and "auto-updates") with some error handling to warn about invalid values and help users migrate from previously valid values (e.g. "1", etc).
Based on my understanding of the discussion it seems the generally preferred approach would be:
|
@jck112 Sounds right to me! Don't need to be all in this PR if you don't want but, if they are, that might be nice! |
I spent some time working on this but ran into a few implementation details that require some input:
|
@jck112 Do something like |
Are you okay getting rid of Doing $ brew upgrade --greedy
Error: missing argument: --greedy |
@jck112 We can make it
Ah. Annoying. @homebrew/brew any thoughts on how best to address this temporarily? |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
brew style
with your changes locally?brew typecheck
with your changes locally?brew tests
with your changes locally?Fixes: #16735