Previously, we required all formulae and casks to be in a specific
formula or cask directory but did not check any subdirectories.
This commit allows using subdirectories for official taps, the only
ones likely to be big enough to warrant sharding in this way and to
avoid potentially breaking backwards compatibility for existing taps.
This was inspired by the most recent issues with homebrew-cask.
- These are arbitrary length limits that had a load of disables in code.
- The limits were only increasing over time rather than decreasing.
- Fixing the problematic code to be shorter would take a long time for
questionable gain since the problem has been around so long.
- We're not going to make the really long things be any shorter any time soon.
- The instructions in issue 14685 say, pragmatically, "disable all the rubocop
rules we're never going to realistically fix e.g. Metrics/ClassLength". But
that felt like a slippery slope to more _really_ long modules/classes/blocks,
and the limits are here for a reason.
We warn sometimes when we tell people to build from source and it's
not supported but we don't actually warn non-developers when invoking
the various install commands so: let's start doing so.
While we're here, also update the existing messaging to reflect the fact
we're on Mastodon now too and we don't want maintainers being
individually bothered about errors either.
I've tried to balance having messages here vs. having them be so long
at the beginning of installation that they will be missed or be overly
obnoxious.
Currently, doing `brew update-reset homebrew/core` does nothing (not
even return an error). If you want to `update-reset` a given tap, you
must do (the equivalent of)
brew update-reset "$(brew --repository owner/tap_name)"
This isn't very intuitive, so let's do a bit more work in argument
parsing so that the user can just pass a tap name instead of a path to a
tap.
Passing a path to a tap is also still supported.
- This 404 error is from GitHub, and GitHub doesn't give us any more
informations about scopes for the gist endpoint (for some reason). But we can
safely assume, as it happens a lot, that "Error: Not Found" (404) is because
the user hasn't granted their `HOMEBREW_GITHUB_API_TOKEN` the `gist` scope.
Before:
```shell
$ HOMEBREW_GITHUB_API_TOKEN=<token_without_gist_scope> brew gist-logs -p logrotate
Error: Not Found
```
After:
```shell
❯ HOMEBREW_GITHUB_API_TOKEN=<token_without_gist_scope> brew gist-logs logrotate
Error: Your GitHub API token likely doesn't have the `gist` scope.
Create a GitHub personal access token:
https://github.com/settings/tokens/new?scopes=gist&description=Homebrew
echo 'export HOMEBREW_GITHUB_API_TOKEN=your_token_here' >> ~/.zshrc
```
- remove all places we check the flag so it's a no-op now
- flip the messaging to refer to `HOMEBREW_NO_INSTALL_FROM_API` where
relevant
- adjust the documentation
- Use `HOMEBREW_CASK_REPOSITORY` more consistently
- Skip auto-updating homebrew-core for `HOMEBREW_DEVELOPER` too (without
explicit `brew update`)
- Also skip auto-updating homebrew-cask
- flip the messaging to refer to `HOMEBREW_NO_INSTALL_FROM_API` where relevant
- remove some duplicate checks
- better scope checks to just core tap formulae
