- use e.g. `$HOMEBREW_*` for cases where only the environment variable
is the entire backtick-quoted string
- use e.g. `${HOMEBREW_*}` for cases where the environment variable is
part of a backtick-quoted string to make clear what parts are variable
and what parts are not
- use `export HOMEBREW_*=...` for cases where we're talking about
setting the environment variable (because it likely needs to be
exported to work how they want)
Inspired by https://github.com/Homebrew/homebrew-bundle/pull/1579 making
similar changes for Homebrew/homebrew-bundle.
- `reinstall` and `upgrade` no longer mark as installed on request,
with or without names specified, but preserve the version from the
tab instead
- default `install_on_request` to `false` rather than `true`
- only set installed in request in a tab if it's missing rather than
false
Co-authored-by: Michael Cho <michael@michaelcho.dev>
The --build-from-source flag can currently be used without specifying
a formula by name but it doesn't behave the way you'd expect it to.
It will upgrade everything using bottles if they are available and skip
building things from source. This is intentional because we want to
discourage non-developers from building packages from source since the
result is less predictable.
The change here is to error out in that case. It might be smarter to
go through the entire deprecation cycle here just in case someone
is using this in scripts.
This adds a new method to either move the `gh` formula to the front
of the formula list to be installed or checks that the `gh` formula
is already installed some other way.
The `Homebrew::CLI::NamedArgs` class often returns frozen arrays so this one cannot
be easily modified in-place here. We just overwrite it instead.
I also updated the `brew reinstall` command logic to match for consistency.
```console
$ brew upgrade gh --verbose --debug
...
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FromAPILoader): loading gh
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::FromAPILoader): loading gh
Error: can't modify frozen Array: [#<Formula gh (stable) /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/g/gh.rb>]
/usr/local/Homebrew/Library/Homebrew/cmd/upgrade.rb:139:in `delete'
/usr/local/Homebrew/Library/Homebrew/cmd/upgrade.rb:139:in `run'
/usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/3.3.0/gems/sorbet-runtime-0.5.11481/lib/types/private/methods/call_validation.rb:270:in `bind_call'
/usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/3.3.0/gems/sorbet-runtime-0.5.11481/lib/types/private/methods/call_validation.rb:270:in `validate_call'
/usr/local/Homebrew/Library/Homebrew/vendor/bundle/ruby/3.3.0/gems/sorbet-runtime-0.5.11481/lib/types/private/methods/_methods.rb:277:in `block in _on_method_added'
/usr/local/Homebrew/Library/Homebrew/brew.rb:95:in `<main>'
```
This updates logic to add a `#scheme_and_version` method to be used
with `.sort_by` and `.max_by`. Using `Keg#version` by itself can be
inaccurate when different version schemes are present. This also
updates the behavior of `Formula#eligible_kegs_for_cleanup` to match
the previous behavior. We were dropping the wrong keg based on the
sort being reversed in a previous PR.
`FormulaInstaller` already supports this (https://github.com/Homebrew/brew/pull/12691) but I didn't wire it up via `brew upgrade` and the two can be used largely interchangeably
The idea here is that it should be expected that `brew upgrade` will
not upgrade pinned packages but will attempt to upgrade everything else.
For that reason, it will only show a warning about pinned packages
in that case.
If, on the other hand, you pass the name of a pinned package explicitly
to the upgrade command, like in `brew upgrade PINNED`, we want to show
an error since we cannot upgrade that package until it gets unpinned.
The hope is that this will be clearer and less annoying for users.
A user came to us a couple weeks ago stating that it was confusing
that the `brew upgrade` command printed an error when a pinned
formula had a new version available and didn't get upgraded.
This PR changes that message to a warning from an error. While looking
into this we found that there is another message that gets printed
when a package dependency doesn't get upgraded because it is pinned
and that got turned into a warning from a normal message. Honestly,
that should be more worrying for the user anyway; it could lead to
a program not working correctly in the worst case.
I also added a message to the `brew pin` command warning about
potential unintended behavior if a dependency gets pinned and another
package requires a newer version of it.
Lastly, I added a commented out deprecation notice for the
`brew upgrade --ignore-pinned` command since it's now the default.
