This saves an API call, and is more accurate, because the repo API
doesn't actually say whether forking is enabled, but this error message
does.
To do this, the original GitHub error message had to be accessible on
the GitHub exceptions.
GitHub seems to be discouraging forking private repositories[0]:
> By default, new organizations are configured to disallow the forking
> of private repositories.
bump-formula-pr tries to create its pull requests from a fork, so it
can't be used for private taps set up in this way.
I've added a --no-fork option that will create PRs in the tap repo
itself, rather than in a fork, to accommodate this use case.
[0]: https://help.github.com/articles/allowing-people-to-fork-private-repositories-in-your-organization/
This was accounted for in Version::NULL.<=>, but not in Version#<=>,
so these could only be compared if Version::NULL was the left hand
side.
The check had to go above the check that `other` is a version because
`Version::NULL`'s anonymous class does not inherit from `Version`.
(The type check feels like it's probably a smell, but out of scope).
An installed formula doesn't get optlinked until _after_ it's installed,
meaning that we can't rely on `opt_prefix` to get the right keg.
So, if not optlinked, fall back to the formula's prefix, which will be
that of the current installation.
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.
Auditing a formula with this structure (plus a `desc` statement)
results in an audit warning:
> * C: 12: col 3: `include` (line 12) should be put before `desc` (line 2)
I just ran into an issue where a colleague's Homebrew couldn't update.
It seems to have been because it failed once just after the new repo
directory was created. Since there was nothing in this directory, there
really isn't any reason for us to fail here, so to avoid this problem in
the future, try to `rmdir` the directory before failing because it already
exists.
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.
Since this hack is no longer required, and `Emoji.tick` and `.cross` are
only called in one place, I think it's better to just inline them there
rather than having methods on `Emoji` that just return a one-character
String.
This will allow us to have global setup and teardown for tests.
For example, we can automatically clear caches after each test, to avoid
annoying intermittent failures like #1879 and #1886.
Similar to 6fc1747e05. I hadn't seen any
test failures caused by this, but I noticed it in the process of
trackign that down and it's an accident waiting to happen.
This is a temporary measure until:
- #1862 is merged
- I can a test on `brew uses` against every formula in the official
taps to verify that exceptions are no longer raised.
Fixes#1848 by sharing recursive dependency resolution between
dependencies and requirements.
Coincidentally, this also fixes the errors introduced by #1784 that
necessitated it being reverted in #1797.
Fixes#1776.
If any known formula had a dependency on an untapped tap,
Formula#recursive_dependencies would throw an exception, which would be
caught by the outer exception handler, causing the rest of the
dependencies for that formula to be skipped and incomplete output to be
generated.
To fix this, I added a check to avoid analysing the dependencies of
formulae from uninstalled taps.
Additionally, I removed the aforementioned outer exception handler added
in 5fdb89aed9, because the only other
place that should be capable of throwing such an exception is the
statement that was surrounded by another wider exception handler in
Homebrew/legacy-homebrew#40682.
Previously, this returned a String, but a Tap instance seems much more
sensible.
I couldn't find anywhere this method was actually used, so the change
shouldn't break anything.
This had to be added in #1750 to work around special-casing for tabs
generated with Homebrew versions < 1.1.6. Now that 1.1.6 is the current
version, we can remove this hack.
In #1497 I switched from Keg#to_formula for comparing kegs to formulae
to comparing the name and tap in the keg's tab to the name and tap of
the formula.
However, this fails to match if the name and tap of the formula have
changed since the keg was installed, so it's clearly better to use
Keg#to_formula where possible, and fall back to the information in the
tab when #to_formula can't be used.
This is a proper fix to the problem addressed by #1510.
The problem arises when f_kegs is nil, which can happen if the name and
tap used to install a keg don't match the name and tap currently
associated with its formula (i.e. if it's been renamed or moved).
See https://github.com/Homebrew/brew/pull/1750#discussion_r94243825 for
discussion.
Removes Tab#reliable_runtime_dependencies? in favour of returning nil
from Tab#runtime_dependencies if the list is unreliable.
Because Homebrew 1.1.6 hasn't been tagged yet, tabs created in tests
aren't created with a homebrew_version that marks the
runtime_dependencies in the Tab as reliable, so there are some tests
that fail. To work around this, I've had to add a line to some tests
that explicitly overrides the homebrew_version in the Tab. This is
really ugly though, so they should be removed as soon as possible after
1.1.6 is released.
Alyssa Ross