| Age | Commit message (Collapse) | Author |
|---|
|
The backticks will either return a string or raise an exception, so
`executable` cannot be nil.
|
|
|
|
Closes #35257.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
|
|
|
|
|
|
This is as Python bindings are not build in a way that can have
system or Homebrew Python used interchangeably.
|
|
|
|
|
|
|
|
- PythonDependency now implies Python 2.7
- PythonDependency now uses brewed Python for bottling
- Use double-quotes everywhere
Closes #27112.
|
|
|
|
* Only set PYTHONPATH for Python 2.
* Set the Python binary for superenv.
References #24842.
Closes #26197.
Closes #26216.
Closes #26218.
Closes #26228.
|
|
Closes #26067.
|
|
Closes #24842.
|
|
|
|
make sure it doesn't actually point to something else
since sitecustomize.py is put in a location found by pypy,
it breaks pypy by setting sys.executable to a path that is definitely wrong,
and may not even exist.
Closes #24581.
Signed-off-by: Adam Vandenberg <flangy@gmail.com>
|
|
Fixes #24456.
|
|
|
|
Fixes #23837.
Fixes #23866.
|
|
|
|
Make it more consistent with other requirements.
|
|
Improve robustness of `PYTHONPATH` by first unsetting it (during
`satisfy`) so that the `PythonInstalled` can get the `python.version`
and so forth and then, after that, setting the `PYTHONPATH` to our
`global_site_packages`.
In the `python_helper` we append to the `PYTHONPATH` so if that var has
been set in a formula, it is respected.
Brew audit does no longer complain about setting the
`ENV['PYTHONPATH']`.
|
|
that live in the `libexec` dir of a `Cellar`.
|
|
If `depends_on :python => ['modulename', :optional]` then the generated
option is now `--with-python-modulename`, so that it is possible to
actually make depending on python modules optional.
Further, `brew options` becomes more meaningful.
|
|
When a formula `depends_on :python` *and* `depends_on :python3`
the `modify_build_environment` method sets the PYTHONPATH
and the Python 3.x requirement then fails because it finds
the sitecustomize.py from Python 2.x in the PYTHONPATH.
|
|
|
|
|
|
Fixes #22002.
|
|
On Unix, the path separator is ':', whereas on Windows,
it is ';'. This is the first of a series of patch to bring
macbrew's and winbrew's codebases closer together.
The main places the magic constant ':' was being used were:
- the $PATH environment variable
- CMAKE-related environment variables
- pkg-config related environment variables
Closes #21921.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
|
|
Up to now a brewed Python, even if not linked, was preferred over
and external Python, so that you had to completely `brew rm python`
to have a formula link against external (mostly system) Python.
From now on it is okay to `brew unlink python`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Closes #21794.
|
|
In our sitecustomize.py we instruct python to exit with an error message
if the PYTHONPATH is pointing to a wrong homebrew site-packages dir.
With wrong meaning another major python version.
If you set the PYTHONPATH to include
$(brew --prefix)/lib/python2.7/site-packages
and start python3, it may pick up modules from there, wich can result
in errors for non pure python modules (such as PyQt).
|
|
during building of python software inside of a `python do … end` block.
|
|
This will be handled by env/superenv, not Python.
|
|
|
|
eql? should not depend on the hash value as hash values of uneql objects
can collide, but eql values may only collide for objects that are
actually eql.
Further, python dependencies are uniquely identified by the combination
of the name and imports attributes, so there is no reason to involved
the expensive binary computation for simple equality checks.
Fixes #20840.
|
|
|
|
|
|
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"...
|
|
|
|
Some prefer to install with `--user` into their
home. For example to avoid `sudo` with system's
python. Now Homebrew can use those modules to
satisfy a python dependency on a certain module.
|
|
* Fixes #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.`
|
|
Exposing this as "to_a" was a mistake, versions are not arrays and it
causes incorrect behavior when splatted or using Kernel#Array(). Use the
more correct name "tokens" instead.
|
