Add which_python to utils

[jacknagel]

Enough formulae use this:

def which_python
  "python" + `python -c 'import sys;print(sys.version[:3])'`.strip
end

that it is probably worth moving it into utils or something.

[jacknagel]

And standardize the PYTHONPATH caveats across formulae.

[MikeMcQuaid]

Sounds good.

[jacknagel]

Hmm, probably needs a better name than "which_python", too.

[samueljohn]

Great!
I suggest python_version -> "2.7" because sometimes we just need the major.minor numbers.
Further which_python -> "python"+python_version.

[adamv]

I'd suggest an object which gets instantiated as "MacOS.python", which has subproperties for various things.

[samueljohn]

@adamv excellent idea.
Sometimes we just need "2.7" and sometimes "python2.7". Further, we often need HOMEBREW_PREFIX/lib/python2.7/site-packages`. A shorthand for that would be nice!

PYTHONPATH=#{HOMEBREW_PREFIX}/lib/#{which_python}/site-packages:$PYTHONPATH

Further, I'd like to see an object MacOS.python3, too.

[Sharpie]

After discussion in #14579, the idea of a Requirement for Python was brought up. Possible issues to be addressed and cleaned up:

• Checking to see that python has a sane PYTHONPATH.
• Centralizing the which_python method, which is used by at least 20 formulae in core.
• Centralizing checks for whether Python is built as a Framework and what the appropriate lib path and linker flags should be. Currently a block similar to this one in vtk is more or less duplicated across ~6-10 formulae in core.
• Some configure scripts deduce that Python should be linked via -framework Python, but don't add the proper LDFLAGS to ensure Homebrew's framework is found before the system Framework. Notable example is Vim in homebrew-dupes: homebrew/homebrew-dupes#75. Possibly address with better support for Frameworks as proposed by Link Frameworks into HOMEBREW_PREFIX/Frameworks? #14801?
• Add a version parameter a la the :x11 dependency that could be used to provide options for building against Python 3 rather than always defaulting to Python 2 unless the user symlinks python to python3. Possibly should tie into superenv?
• Check to see that Python's distutils is sane and doesn't expect to build against a compiler that no longer exists. Example, Python built with gcc-4.2 running on a machine with XCode 4.x installed: install hg fails with not finding gcc-4.0 #14476 and many others. Possibly should be done in brew doctor?

[samueljohn]

Nice summary, @Sharpie!

1. To @adamv's idea of a Python object:
   • MacOS::Python.version -> "2.7"
   • MacOS::Python.executable -> "python2.7" (replaces which_python)
   • MacOS::Python.site-packages the dir of homebrew's site-packages
   • MacOS::Python.library -> In a framework install it's just "Python"
   • MacOS::Python.include_dir -> For vtk and related (cmake?) projects
   • However, we should not duplicate what is provided by python-config --includes and related.
2. A Requirement checks:
   • Checks the PYTHONPATH (which is sane, if homebrew's site-package dir is included, I guess.)
   • Prints the caveat about the PYTHONPATH (only if no brewed python is found)
   • Check that the distutils CC compiler is ok (and perhaps other things)

Concerning Cmake based formulae, @2bits is in my eye now the pro here :-)

And I am yet undecided whether a EVN.python and ENV.python3 might be more flexible, because one could set the first, build the python bindings and then set the latter to build python3 bindings. That would need some experiments.

[Sharpie]

Agreed that this should probably be split into several objects---a Requirement that does sanity and version checks when supplied to depends_on and one that is easily accesible inside the install block that can be used to set library paths.

A few notes:

MacOS::Python.library -> In a framework install it's just "Python"

Should be something like: -F#{python.prefix}/Frameworks -framework Python. That works for Homebrew installations, but lifting the correct prefix from a System or 3rd-party install will be more difficult. Perhaps theres a python-config option or something in the sys module we can exploit here.

We should also check the Python architecture. There have been a few reports arising from people using 32-bit only distributions such as EPD.

[jacknagel]

Let's think hard before sticking any of this in the MacOS module; I think a new namespace would be much better.

[adamv]

If not MacOS then what's a good top-level namespace? Scripting::ruby and Scripting::python?

[samueljohn]

I like that. Perhaps I should just start to write this :-)

[adamv]

I'm going to start

[samueljohn]

Even better! I can tweak the python side later on.

[samueljohn]

@adamv what happened to your scripting branch?

[samueljohn]

@adamv I'd like to continue your work. Cant find your branch, though.

[samueljohn]

I also would like to have something similar to the std_cmake_args for python.
From all what I learned so far, I noted down the best way to install python bindings when a setup.py is provided in the wiki: https://github.com/mxcl/homebrew/wiki/Homebrew-and-Python

That Scripting module would be a wonderful place for something like Scripting::Python.setup_py_args(). I could set perhaps even prepare the temporary sitepackage dir in the Cellar and add it to the PYTHONPATH so that the setup.py does not complain.

[jacknagel]

A good first step, I think, would be to just extract the common python stuff totally as-is into a module that is mixed into Formula.

[samueljohn]

@adamv had it already quite nice, but the branch is gone as far as I can tell. I don't want to duplicate work.

[adamv]

I don't have that branch any more, sorry.

[samueljohn]

May I start a new attempt?

[adamv]

Please do.

[samueljohn]

@Sharpie had the great idea to write a Python requirement which could ensure that there is a sitecustomize.py even if no python has been brewed. (Fixes the .pth files not parsed by other pythons issue)

[samueljohn]

Closing this because I am already working on this and have addresses the suggestions in my python_next branch.

[samueljohn]

being done in --> #18588