-
-
Notifications
You must be signed in to change notification settings - Fork 10.6k
Don't tap user-untapped official taps #10366
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
Conversation
Review period will end on 2021-01-20 at 23:32:51 UTC. |
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.
Nice idea here! I think it might be nicer to reduce the situations in which install_default_cask_tap_if_necessary
is run to only when a e.g. --cask
option or similar is specifically run. Otherwise, if we're looking up "formula or a cask" and it's not tapped: we should simply skip all cask logic. Thoughts?
I think it depends on whether we can assume that the only reason the cask tap wouldn't be installed is that a user actively uninstalled it (if that makes sense). Does the Homebrew installer always tap the cask tap (on macOS)? If so, for how long has it done this? If the answer is no, I don't think we should do that. We want If the answer is yes, I'd be more on-board. I think that means that we can assume that the cask tap being uninstalled indicates an active user choice to untap. We may still want to show a message reminding users (who don't have |
It does not.
Agreed but I don't think it is in any case other than |
Ah, I see. Yeah, we can move the |
Okay, I updated so it will only attempt to tap on |
I've seen this failure many times recently. Not sure what's going on. It seems that simply rerunning the tests fixes it.
|
Review period ended. |
Yeh, it's either order-dependent or failing based on another test that's running. Could ideally try to fix that or bump the retries? |
formulae, casks = args.named.to_formulae_and_casks | ||
.partition { |formula_or_cask| formula_or_cask.is_a?(Formula) } | ||
rescue FormulaOrCaskUnavailableError, Cask::CaskUnavailableError => e | ||
retry if Tap.install_default_cask_tap_if_necessary(force: args.cask?) |
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.
Perfect 🎉
possible_tap = Tap.fetch(possible_tap.first) if possible_tap | ||
|
||
odie "Unknown command: #{cmd}" if !possible_tap || possible_tap.installed? | ||
if !possible_tap || possible_tap.installed? || Tap.untapped_official_taps.include?(possible_tap.name) |
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.
So this logic (and everything related) means that if you untap it: it'll never be automatically retapped?
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.
Yes, that's the idea. Although, if you retap using brew tap homebrew/cask
, it removes homebrew/cask from the homebrew.untapped
setting meaning that it would be retapped automatically in the future if needed (assuming the reason it became untapped was not done using tap.uninstall
. tbh I'm not sure how that would happen).
Actually, now that I'm thinking about it, are there any instances where a tap could be uninstalled and we wouldn't want to write to the setting? Maybe we should only write if a user untaps via the brew untap
command...
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.
Yes, that's the idea. Although, if you retap using
brew tap homebrew/cask
, it removes homebrew/cask from thehomebrew.untapped
setting meaning that it would be retapped automatically in the future if needed (assuming the reason it became untapped was not done usingtap.uninstall
. tbh I'm not sure how that would happen).
Seems good!
Maybe we should only write if a user untaps via the
brew untap
command...
Yeh, maybe?
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 line, in particular, is saying "raise an error saying unknown command if there is no tap found with the given command, the tap with the given command is already installed, or the tap with the given command has been manually uninstalled by the user. Otherwise, continue and autotap"
brew style
with your changes locally?brew typecheck
with your changes locally?brew tests
with your changes locally?brew man
locally and committed any changes?Fixes #10303
This PR modifies the logic for when to automatically tap official taps.
As a refresher, there are two times where an official tap would be automatically tapped:
bundle
,test-bot
, orservices
command and the respective repo isn't tappedargs.named.to_casks
(or other similar methods that convert named args to casks) is unable to match a name to a formula or cask. This is seen mostly when runningbrew install <invalid_formula_or_cask>
orbrew uninstall <invalid_formula_or_cask>
.Now, if a user has untapped an official tap, we will remember this in the Homebrew settings. If a user does one of the above actions that would normally tap the repo, we will first check to see whether they have already untapped the repo. If so, we assume that they genuinely do not want that repo, so we don't re-tap.
A few comments:
Tap.install_default_cask_tap_if_necessary
is used inLibrary/Homebrew/cask/cmd.rb
. Should this be modified to always tap the cask repo, even if the user has explicitly untapped it? I'm not sure if this file will even have a use after Homebrew 2.8.0 (wherebrew cask
commands are removed).Tap.untapped_official_taps
to avoid repeating theuntapped = Settings.read(:untapped) || []
line in many places. I didn't for now simply because I wanted to get this PR up for feedback.CC: @carlocab, @fxcoudert, and @jonchang