When a requirement is specified like:
satisfy { which "foo" }
There is no reason that we should inject all of ENV.userpaths! into the
build environment. Instead, infer the directory to be added to PATH from
the Pathname that is returned.
This is another step towards condensing the "which program" requirements
down into a one-liner DSL element.
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.
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.
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.
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.
To allow
depends_on :x11 => :optional
and friends to work as expected, make requirements record any tags and
add special handling to the X11Dependency to record both a minimum
version and additional tags.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
* Renames --force to --overwrite, freeing up brew ln --force for Homebrew/homebrew#13349
* Changes --dry-run to preview linking by default, rather than
overwriting. An overwrite dry-run can be simulated via both
--dry-run --overwrite
* Adds some basic Keg tests
While at it, make it use class methods instead; no reason to instantiate
an object for this.
Eventually there should be some functional tests for the individual
strategies as well.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
ComparableSet only allows a single object of a given class,
choosing the object with the greatest value. This was mainly created
for Requirements, so that, e.g., two X11Dependencies of differing
strictness don't both end up in the same requirement set.
FixesHomebrew/homebrew#15240.
The changes to error ouput and logging require a few more things to be
visible during installation tests.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
It is a no-op under Ruby 1.8 but Pathname#find raises ENOENT if the
directory doesn't exist under 1.9. But we really shouldn't try to clean
a non-existent keg anyway, and FormulaInstaller will have bailed out
long before the clean step if the keg doesn't exist, so lets just not
even test this condition; the cleaner has its own tests anyway.
Alternatively we can adjust the cleaner to handle this case, but I don't
see much value in that.
n.b. with this, the tests now pass under 1.9.3 (for me), which is nice
because I often run them on that version inadvertently.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
It has been long enough since `depends_on :x11` was introduced that we
can make it the caller's responsibility to ensure X11 is present before
invoking ENV.x11, so stop outputting a warning.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
If the rcov gem is installed, `rake rcov` will generate a test coverage
report in the coverage directory.
I picked rcov because it is 1.8 compatible. But it could easily be
swapped out for another coverage tool.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
The heuristic used by the default version comparison is simple. A
version string is scanned for strings of digits, split into an array of
these strings, and then an element-wise comparison is done.
This fails when presented with something like
Version.new("1.0.0beta7") <=> Version.new("1.0.0")
because the first three digits match, and the fourth digit of the
receiver (7) is greater than the assumed fourth digit of the parameter
(0).
Fix this by defining an element-wise comparator on a new VersionElement
class. This allows us to correctly compare "alpha", "beta", and "rc"
style version strings, and keeps the logic out of the main version
comparison.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
This will allow us to do comparisons like
if MacOS.version >= :lion
and hopefully deprecate the MacOS.<name>? family of methods, which are
counterinitutive.
A version scheme is a class that inherits from Version and reimplements
Version#<=>. This will allow formulae to specify a custom comparison
method that will be used instead of the default, for cases where the
default is insufficient.
