Instead of overriding #satisfied?, Requirement subclasses can specify
the condition in a block:
satisfy do
some_condition?
end
The contents of the block are evaluated in the context of the instance,
and so have access to instance variables and instance methods as before.
Additionally, it is wrapped in an ENV.with_build_environment block. This
can be disabled by passing :build_env => false to satisfy:
satisfy :build_env => false do
some_condition?
end
Not thread safe! But I don't think we care.
We want to evaluate the env DSL block in the context of ENV for asthetic
reasons, but we also want access to methods on the requirement instance.
We can use #instance_exec to pass the requirement itself into the block:
class Foo < Requirement
env do |req|
append 'PATH', req.some_path
end
def some_path
which 'something'
end
end
Also add a simplified version of Object#instance_exec for Ruby 1.8.6.
If the repository is set up by `brew update`, the remote URL is
https://github.com/mxcl/homebrew.git, but if it is set up by the install
script, the .git suffix is omitted.
This contains updates to the OkJson library that allow objects to define
to_json for serialization, and this will be used in the upcoming options
and deps work.
Added checks on doctor.rb for:
* Missing git origin
* git origin not pointing at mxcl/homebrew
Tests use `git config --get remote.origin.url`.
Also added printout of origin to --config.rb.
FixesHomebrew/homebrew#14399.
ClosesHomebrew/homebrew#17117.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
The DependencyCollector tests are really integration tests, while the
rest are closer to real unit tests. Split them up so that the tests can
be run in isolation on a per-class basis.
It is important that dep equality corresponds to the name attribute, but
we may want to use the Comparable interface to sort them by installation
order in the future. Code that needs to sort them alphabetically should
just use sort_by.
* Detect `latex' and `bibtex' commands.
* Recommend installing MacTeX when no LaTeX installation is found.
Signed-off-by: Adam Vandenberg <flangy@gmail.com>
Commit 30a08f5cc707 ("Don't attempt installation multiple times") was
correct in raising FormulaInstallationAlreadyAttemptedError early enough
to prevent the other exceptions in #check_install_sanity from being
raised, but it should not have moved the point at which formulae are
added to the attempted set. Doing so prevents the installer from being
instantiated multiple times on the same formula, even if installation
was never attempted.
Put it back where it belongs.
- Name of the brewed formula in "Summary" heading.
- At the beginning of the summary line a 🍺 is given out
(but only on Lion or above). This acts as a nice
visual marker for the end of a brew-ing process.
- When brewing a dependency, the name is highlighted in green.
- `oh1` is bold, too (like ohai).
ClosesHomebrew/homebrew#16020.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
When a dependency of a formula specified on the command-line is also
specified, *after* the dependent formula, installation proceeds as part
of the dependent's dependency tree and then is attempted again because
the user asked for it explicitly. This results in the installer raising
a CannotInstallFormulaError because it has already been installed.
For example:
$ brew install graphviz pkg-config
==> Installing graphviz dependency: pkg-config
...
==> Installing graphviz
...
Error: pkg-config-0.27.1 already installed
We already have a mechanism for dealing with this, but it does not kick
in early enough. Move the installation attempt check into
FormulaInstaller#check_install_sanity and catch the exception in the
appropriate places.
FixesHomebrew/homebrew#16957.
Procs cannot be marshalled, but formula objects may be as part of the
BuildError exception. If the formula object has a reference to a Proc,
this will fail.
Work around it by not storing the test Procs during installations.
Ruby 1.8.6 doesn't have Symbol#to_proc, which allows things like
map(&:to_s) rather than map { |o| o.to_s }. 1.8.7 does, though, and
since it is used in a bunch of the superenv code we should attempt to
keep it compatible with 1.8.6.
ClosesHomebrew/homebrew#16046.
`python --version` doesn't work in some (very) old versions of
python. While I doubt this is going to come up very often, it's
theoretically possible someone has an old python first in their
path. (python -V works on all versions I'm aware of, including
python3, and comes before --version in the --help anyway.)
Also skips the warning in case the regexp matches nothing, which
probably shouldn't happen. But if it does we shouldn't produce the
wrong warning.
Inheriting from Array (and other core types) is problematic:
- It exposes a very wide interface with many methods that are not
really relevant to the subclass.
- It can cause some weird side effects, as many Array operations are
in C and have hardcoded return values; for example, combining two
array subclasses returns a new Array instead of the subclass.
Avoid these problems using delegation and the Enumerable module where
applicable.
