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.
Provide `OS::Mac.prerelease?` for pre-release checks and use it where
appropriate. This should simplify updating the test once a new OS X
release lands.
This also fixes a bug in `BuildError#dump`, where an empty warning
message was printed on El Capitan after a failed from-source build,
because the check there and the one in `check_for_unsupported_osx` were
out of sync.
ClosesHomebrew/homebrew#45257.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Add these new errors, and guards in formula installation and
cmd/{,un,re}install to match, move can_build? to the MacOS module,
flatten conditions, remove redundant can_build? check
reinstate removed (doctor) check
Mike McQuaid