Note, in the explict form:
PythonInstalled.new('2.7') => :recommended
the tag :recommended is ignored (not a limitation
of PythonInstalled itself). One solution was to write
PythonInstalled.new('2.7', [:recommended])
but that is not as beautiful as we like it.
Therefore, now it is possible to:
depends_on :python => ['2.7', :recommended]
Only the first tag is attempted to be parsed as
a version specifyer "x" or "x.y" or "x.y.z"...
* FixesHomebrew/homebrew#20572 by tweaking the logic that decides
which python is used by the `python` object
inside a formula. There was a bug when on 10.6
there is no Python 2.7 but a :recommended
Python was still treated as being available.
* Use the user's PATH when looking for an external
Python. Until now only brewed or OS X system's
python have been found by `depends_on :python`.
But now we support any Python in PATH (e.g.
pyenv's python).
* Further, instead of handling python modules
and import tests in LanguageModuleDependency,
these are now handled by:
depends_on :python => 'numpy' # for example
The old style
depends_on 'numpy' => :python
is still supported and is only an alias
for the newer style (only for :python, the
other languages are not altered by this commit).
The reasoning is that if a formula requires
a python module, it basically also needs
python itself - and further that specific
version of python has to provide the module.
So the `PythonInstalled` is the natural place
to check for the availability of a python
module.
Using a python module and other tags like
:optional or :recommended is done like so:
depends_on :python => [:optional, 'numpy']
Specifying another PyPi (Python Package index)
name than the module import name is seldom used
but supported, too:
depends_on :python => ['enchant'=>'pyenchant']
A last note: For clarity, you can define
multiple depends_on statements with different
modules to be importable.`
This allows formulae which won't build with Tiger's ld to conditionally
request a dependency on the ld64 formula. This modifies the build
environment appropriately, and will only be active on Tiger.
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.
By always passing around a single, unnested array rather than splatting
and then defensively flattening and compacting things, we can avoid
allocating a bunch of unnecessary arrays. This gives a performance boost
of roughly 4% when enumerating 2500 formulae, and has the side effect of
cleaning up the dependency API.
Currently we check if "tag" is present in LANGUAGE_MODULES for every
String dep, even if tag is nil. Stop doing this, and make the
LANGUAGE_MODULES array into a Set instead to improve lookup performance.
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.
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.
