feat: Allow passing one or more --tap options to brew update to allow specific taps to be updated
#14530
Conversation
Instead of on both lines 567 and 726
…pecific taps to be updated Square distributes internal tools through a private tap of Homebrew formulas. It's common for Square engineers to have also tapped other repos of Homebrew formulas, both public and private. We have mechanisms to ensure that our internal tools are up-to-date — and we need to make a strong guarantee that those mechanisms work. However, they can currently fail to `brew update` our critical tap if any other tap is broken for any reason (e.g. its remote branch was renamed, the user's SSH key is missing, you need to be on a VPN to see some other private tap, etc). A variety of workarounds are at our disposal, but the cleanest of all would be the ability to express to `brew update` the list of taps we want to update the way we can express to `brew install` or `brew upgrade` the list of formulae we care about.
| if [[ " ${ALLOWLISTED_TAPS[*]} " == *" ${tap} "* ]] | ||
| then | ||
| DIRS+=("${DIR}") | ||
| fi |
There was a problem hiding this comment.
NOTE: This implementation ignores invalid taps. I think this is correct b/c it's treating "${HOMEBREW_LIBRARY}"/Taps/*/* as the source-of-truth and the users' arguments as a filter, but do you think it should print a warning in this scenario? Like:
$ brew update --tap=homebrew/core --tap=nope/nope
Tap nope/nope is not installed.
You can tap it with brew tap nope/nope.
|
@boblail I'm not sure I understand the desire for the feature, can you elaborate on why you'd only want certain taps to be updated and not others? Note that |
|
@MikeMcQuaid, here's our use-case. We have a bootstrap tool that's foundational, minimal, and idempotent. It runs often. It guarantees that you have access to our private repos, access to our private tap, and current versions of one public and two internal formulas. (Just about everything else that runs on laptops depends on this guarantee.) The bootstrap tool uses Ideally, our tool would just I didn't know about |
It's documented in
They will miss out on the updates, reporting, rename migrations, etc. that
Does this not break e.g. auto-updates too? As-is I'm afraid I'm leaning towards declining this. I just don't see a good reason to add a new command when |
|
@MikeMcQuaid, how about if I try out using |
|
Maybe it makes more sense to prevent |
|
I have a very similar (or exact) need and also didn't know However I am not sure how to use |
brew update-reset "$(brew --repo company/tools)"But we really should fix that. |
|
@nemith Can you elaborate on why you have this need? What are the things that are causing |
|
Yeah, like @boblail I am investigating using homebrew to distribute internal tools however we have a private instance of Github Enterprise which is only accessible on VPN. Out-of-date tools is more of a concern as we want to do releases often and a lot of our users are will not be power homebrew users and automatically updating. So to combat out-of-date packages we want to include a outdated_check into the binary itself to tell the user that a new version is available. This needs to be fast and quick so updating just a our single repo and then doing a The other side of this is when off vpn the tools should still work and maybe not error out on the unaccessable repo, but that is less of a concern right now. Most of this is in the design stage. |
@boblail @nemith I tested this out and cannot reproduce this behaviour. As far as I see, if I don't understand what the desired behaviour is here? |
|
@carlocab was the one who suggested not failing on update. That isn't the behavior/issue I was describing so I have less of an issue there. There is a bit of an issue with the error messaging in the fact it's "fatal" errors which give the impression that not all repos are fetched but I guess that may not be something you desire to fix. My specific issue was being able to check for outdated recipes quickly during tool invocation which brew update is faster but not fast enough. Like i said before I am still evaulating solutions (being able to install other versions or canary versions is also important to me) so perhaps I have a round hole that i am trying to shove a square peg through. Feel free to disregard my comments. |
This is output by
Yeh, not sure we can help there, sorry! |
|
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. |
|
Passing on this, sorry! |
Square distributes internal tools through a private tap of Homebrew formulas. It's common for Square engineers to have also tapped other repos of Homebrew formulas, both public and private. We have mechanisms to ensure that our internal tools are up-to-date — and we need to make a strong guarantee that those mechanisms work. However, they can currently fail to
brew updateour critical tap if any other tap is broken for any reason (e.g. its remote branch was renamed, the user's SSH key is missing, you need to be on a VPN to see some other private tap, etc). A variety of workarounds are at our disposal, but the cleanest of all would be the ability to express tobrew updatethe list of taps we want to update the way we can express tobrew installorbrew upgradethe list of formulae we care about.brew stylewith your changes locally?brew typecheckwith your changes locally?brew testswith your changes locally?