This provides clarify to users about the support tiers for Homebrew.
Co-authored-by: Douglas Eichelberger <697964+dduugg@users.noreply.github.com>
Co-authored-by: Bo Anderson <mail@boanderson.me>
Co-authored-by: Sam Ford <1584702+samford@users.noreply.github.com>
This uses the logic in `brew.sh` for deciding whether or not to run
`brew update --auto-update` and makes it a dedicated command that can
be used instead of `brew update` in scripts to be really fast in the
no-op case.
`brew update` will always do at least some updating which is a nicer
default but is much slower.
We've had requests for this in Homebrew/bundle a few times so let's
implement it both for there and for `brew edit`.
Tested on my machine with `cursor` and working as expected.
This was in the (soon to be archived) Homebrew/homebrew-bundle
repository's `README`. There's some good content here that doesn't
cleanly fit into the `brew` manpage so let's move it here.
While we're here, let's de-emphasize `whalebrew` as it's not
widely used and add commented-out deprecation warnings for its future
deprecation.
This new part of documentation has been added in order to provide
users a way to identify curl related issues which may or may not be
caused by their workstation.
Based on discussion in #19408, update the documentation to specify that `:pwsh` must be passed explicitly and that it will translate to a "powershell" argument, as is currently supported by Go's common `github.com/spf13/cobra` module and Rust's common `clap` (with `clap_complete`) crate.
Some RubyDoc URL fragments in the Formula Cookbook documentation
include an equals sign (`%3D`) but the `id` attributes in the current
RubyDoc HTML don't include the equals sign, so the documentation CI
job is failing with errors like `External link
https://rubydoc.brew.sh/Formula#revision=-class_method failed:
https://rubydoc.brew.sh/Formula exists, but the hash
'revision=-class_method' does not`. This updates the URLs to remove
`%3D` accordingly.
I initially set the type for livecheck's `post_form` and `post_json`
hashes to allow either a string or symbol key. I used string keys in
the documentation, as there will inevitably be some form field names
that would pose a problem for symbols (e.g., `E-mail` uses a hyphen,
`1twothree` starts with a digit, etc.). However, I remembered that we
can simply use quote symbols like `:"E-mail"` to handle these
situations, as they have the flexibility of a string while still being
a symbol.
With that in mind, this updates related type signatures to only allow
symbol keys and updates documentation and tests accordingly. The
documentation example contains a hyphenated form field, so it
demonstrates how to handle names that don't work as a bare symbol.
Inspired by @jvns' [post][1], I realized that I've had this problem on multiple teams, where someone missed the step at the end and didn't know how to recover. Typically, I've provided a version like what I've added to the Tips 'n' Tricks page so that I didn't have to think about what OS-arch pair my users are using.
I've tested the loader added to tips and tricks with both bash and zsh and it passes both shellcheck and shfmt in posix mode.
[1]: https://mastodon.social/@b0rk@jvns.ca/113997565198024027
- Most of these were fine still, apart from:
- FAQ: `hub` is less maintained than `gh`.
- Brew-Maintainer-Guide: link to GitHub docs on commit signing via GPG or SSH.
- Interesting-Taps-and-Forks: remove outdated information about `homebrew/core` being in `Library/Taps`.
- New-Maintainer-Checklist: remove outdated information about the `@members` team.
Import these from the homebrew/aliases tap and deprecate that tap.
This required a little messing around with class/module/constant names
to get `brew tests` and `brew typecheck` to play nicely.
I added also added Sorbet type signatures and integration tests.
livecheck currently doesn't support `POST` requests but it wasn't
entirely clear how best to handle that. I initially approached it as
a `Post` strategy but unfortunately that would have required us to
handle response body parsing (e.g., JSON, XML, etc.) in some fashion.
We could borrow some of the logic from related strategies but we would
still be stuck having to update `Post` whenever we add a strategy for
a new format.
Instead, this implements `POST` support by borrowing ideas from the
`using: :post` and `data` `url` options found in formulae. This uses
a `post_form` option to handle form data and `post_json` to handle
JSON data, encoding the hash argument for each into the appropriate
format. The presence of either option means that curl will use a
`POST` request.
With this approach, we can make a `POST` request using any strategy
that calls `Strategy::page_headers` or `::page_content` (directly or
indirectly) and everything else works the same as usual. The only
change needed in related strategies was to pass the options through
to the `Strategy` methods.
For example, if we need to parse a JSON response from a `POST`
request, we add a `post_data` or `post_json` hash to the `livecheck`
block `url` and use `strategy :json` with a `strategy` block. This
leans on existing patterns that we're already familiar with and
shouldn't require any notable maintenance burden when adding new
strategies, so it seems like a better approach than a `Post` strategy.
