In #7526 a comparison for `paths` was introduced, but if `paths` is ever
`nil`, this triggers an error.
Coercing the variable to an Array should alleviate this problem, as
`nil.to_a` produces an empty and comparable Array.
Fixes#7540
Signed-off-by: Mike Fiedler <miketheman@gmail.com>
Remove usage where `Homebrew.args` could be used instead or, due to the
`Homebrew.args` parsing, there was dead code that was never executed
(and no-one complained about not working).
Even if the `version_scheme` does not match: we should never try to
`upgrade` (or show `outdated`) for two identical `pkg_version`s.
If this is ever needed: a `revision` bump should be done instead.
Fixes#7507
We don't remove `etc` files on uninstall. Now we have `pkgetc`, though,
we have a pretty decent guess at what files in `etc` may belong to a
given package and can warn about them being left around on uninstall.
Thoughts: should we do the same thing for `var`? I don't see it being
used nearly as consistently.
Instead of cleaning every time if the file is missing: don't clean this
time, touch the file and clean when it's next needed.
Now that this feature has been around for longer this makes more sense
for existing installations and stops the first `brew install` run on a
new/test installation without this file always running a `brew cleanup`.
Also, fix up the use of a compat/deprecated method hit by tests by
this change.
Fix breaking options on taps again (second time in two weeks, sob).
To avoid doing this again: also add a test for this case (that I've
verified would have caught these cases).
Also remove default `--with-label` value and add `--without-approval`
option.
Reviews could be automatically dismissed on new commits pushed (there is
an option for that in repository settings on Github). That is not the
case for labels. They remain attached to a PR, even when new commits are
pushed. This is undesirable and creates security concerns, because
someone could introduce untested code just before the automerge happens.
Co-authored-by: Eric Knibbe <enk3@outlook.com>
I interpreted the existing message as meaning "you don't pin
a tap any more, rather you pin a specific formula from that
tap". I.e. the command still worked, but it had to be done
on a per-formula basis (eg. `brew tap-pin linuxbrew/xorg/mesa` instead
of just `brew tap-pin linuxbrew/xorg`)
IMO, this makes it clearer that the command itself is no longer
supported.
Refactor the CLI::Args module so it doesn't have different paths to
check arguments depending on whether the arguments have been parsed or
not. Instead, set the values we need from the global ARGV at
first, global initialisation time where they will be thrown away when
the actual arguments are parsed.
To do this some other general refactoring was needed:
- more methods made private when possible
- e.g. `HEAD?` used consistently instead of `head` before arguments
are parsed.
- formula options are only parsed after named arguments are extracted
This should provide a more "type-safe" way of referring to the `etc`
directories of other formulae e.g.
https://github.com/Homebrew/homebrew-core/pull/54257 so that the output
will change if the formula name changes.
- Rename `cmdline_args` to `argv` to make it more obvious where they
come from.
- Make the `if args_parsed` early return into `unless args_parsed` to
(hopefully) make it clearer that this is not the "normal" case and
to not check `argv` unless arguments haven't been parsed.
User may specify which cURL and Git to use via
HOMEBREW_CURL_PATH and HOMEBREW_GIT_PATH.
So, let's use these to determine whether we need to use
their vendored alternatives.
As-of https://github.com/Homebrew/homebrew-portable-ruby/pull/100 we've
removed ARM builds for Portable Ruby due to months of breakage.
Similarly, when we last bumped Portable Ruby the ARM build was much
delayed but, despite Homebrew/brew being completely unusable to anyone
using it on ARM in that case, no-one complained or filed issues.
Instead of attempting to maintain and update a Portable Ruby on niche
(Homebrew) platforms like ARM (or, in past/future PPC) improve the
messaging to provide users with a workaround.
Now we allow only a major/minor version match it should be pretty
doable for those users to install e.g. a prebuilt Ruby binary from a PPA
or built it from source if needed using `ruby-build` and `rbenv`.
The messaging could be improved further but we're somewhat limited by
`ruby.sh` and `vendor-install.sh` being separate. I'm tempted to combine
them (or at least have `vendor-install.sh` not be so generic as to not
be able to give Ruby-specific advice).
