It only makes sense to tell a user to try installing from a bottle if
there are bottles available for them to install for all the formulae
they specified.
Improve the messaging around `brew install` when there's a possible user
action such as an `upgrade` or `link` and don't tell people to
`install --force` when it's unnecessary.
While I did this, tweak the output and function usage in a couple of
related places.
Some example output before this change:
```
Warning: openssl is a keg-only and another version is linked to opt.
Use `brew install --force` if you want to install this version
Warning: mysql@5.6 is a keg-only and another version is linked to opt.
Use `brew install --force` if you want to install this version
Warning: analog-6.0_1 already installed
Warning: bash-completion@2-2.5 already installed, it's just not linked.
```
Some example output after this change:
```
Error: openssl 1.0.2k is already installed
To upgrade to 1.0.2l, run `brew upgrade openssl`
Warning: mysql@5.6 5.6.36_1 is already installed
Warning: analog 6.0_1 is already installed
Warning: bash-completion@2 2.5 is already installed, it's just not linked.
You can use `brew link bash-completion@2` to link this version.
```
I added a new `FormulaUnreadableError` subclass of
`FormulaUnavailableError` so existing `rescue`s of
`FormulaUnavailableError` handle this as well.
The new subclass will output the name of the formula with the error
(because this isn't always obvious from the original exception message)
followed by the original error message.
Fixes#1927.
`virtualenv_install_with_resources` will now attempt to guess the
desired Python based on the active build options and based on the
dependencies and requirements. When the situation is ambiguous (e.g.,
`depends_on :python3` and `build.with? "python"` is true) raise
`FormulaAmbiguousPythonError` unless `:using => "python"` or
`:using => "python3"` has been passed to resolve the ambiguity.
In most cases, this will allow
```
virtualenv_create(libexec, "python3")
virtualenv_install_with_resources
```
to be changed to just
```
virtualenv_install_with_resources
```
Not quite a mass replacement as I've used OS X and Mac OS X where
describing specific older versions and added compatibility methods
for things in the DSL.
`any?` is not the opposite of `empty?`. Besides the case that
`[false, nil].any?` will return false, `any?`(O(n)) has much worse
performance than `empty?`(O(1)).
Makes `tap` re-runnable and unshallows when requested with `--full`.
Tapping with a different URL raises an exception.
The homebrew/core tap cannot be untapped with `untap` so running
`brew tap --full homebrew/core` is now a built-in way to get a full
clone of this tap without resorting to workarounds.
Closes#17.
Signed-off-by: ilovezfs <ilovezfs@icloud.com>
The "apply" DSL method can be called from patch-do blocks to specify
the paths within an archive of the desired patch files, which will be
applied in the order in which they were supplied to the "apply" calls.
If "apply" isn't used, raise an error whenever the extracted directory
doesn't contain exactly one file.
The "apply" method can be called zero or more times within a patch-do
block with the following syntaxes supported:
apply "single_apply"
apply "multiple_apply_1", "multiple_apply_2"
apply [array_of_apply]
If apply must be used, a single call using the second syntax above is
usually best practice. Each apply leaf should be the relative path to a
specific patch file in the extracted directory.
For example, if extracting this-v123-patches.tar.gz gives you
this-123
this-123/.DS_Store
this-123/LICENSE.txt
this-123/patches
this-123/patches/A.diff
this-123/patches/B.diff
this-123/patches/C.diff
this-123/README.txt
and you want to apply only B.diff and C.diff, then you need to use
"patches/B.diff" and "patches/C.diff" for the lowest-level apply leaves.
The code was provided by Xu Cheng. Any mistakes are mine.
