New `depends_on :python` Dependency.
New `depends_on :python3` Dependency.
To avoid having multiple formulae with endings -py2 and -py3,
we will handle support for different pythons (2.x vs. 3.x)
in the same formula.
Further brewed vs. external python will be transparently supported.
The formula also gets a new object `python`, which is false if
no Python is available or the user has disabled it. Otherwise
it is defined and provides several support methods:
python.site_packages # the site-packages in the formula's Cellar
python.global_site_packages
python.binary # the full path to the python binary
python.prefix
python.version
python.version.major
python.version.minor
python.xy # => e.g. "python2.7"
python.incdir # includes of python
python.libdir # the python dylib library
python.pkg_config_path # used internally by brew
python.from_osx?
python.framework?
python.universal?
python.pypy?
python.standard_caveats # Text to set PYTHONPATH for python.from_osx?
python.if3then3 # => "" for 2.x and to "3" for 3.x.
Further, to avoid code duplication, `python` takes an optional
block that is run twice if the formula defines depends_on
:python AND :python3.
python do
system python, 'setup.py', "--prefix=#{prefix}"
end
Read more in the Homebrew wiki.
This was meant to support:
env do |req|
append_path 'PATH', req.some_method
...
end
i.e., the block was evaluated in the context of ENV. But it turned out
to be not so useful after all, so I'm ripping it out before something
actually depends on it.
The name attribute of requirements is used when generating options for
the :optional and :recommended dependency tags.
Unless otherwise specified, the name attribute of a Requirement will be
populated by stripping any module prefixes from the beginning and
"Dependency" or "Requirement" from end of the class name and downcasing
the result.
ClosesHomebrew/homebrew#17759.
Expand requirements recursively while applying the same optional? and
recommended? filters that dependencies are run through. Options
generated by requirements are now checked against the correct list of
requirements, eliminating the temporary "best guess" logic in the
installer.
When a formula's dependency tree contains more than one X11 dependency,
they are de-duplicated by comparing the min_version attribute. However,
this can result in broken dependency trees if one of the X11Dependency
objects was actually specified as e.g. `:libpng`.
In practice, this only matters when one or more of the dependencies has
additional metadata that makes it distinct from the rest, i.e. an
:optional or :recommended tag.
To combat this, make these special, "partial" X11 dependencies instances
of different classes so that they are not de-duped.
It will still be necessary, at the time when requirements are expanded
by the installer, to de-duplicate any remaining X11 dependencies after
applying the optional/recommended filters in order to avoid duplicated
modifications to the environment (as ENV.x11 is not idempotent).
c.f. Homebrew/homebrew#17369.
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.
