On Mar 30, 2011, at 2:49 PM, David Maxwell wrote:
Barry, Andy:
I suppose you can avoid both these gotchas by involving the end user in the choice rather than making it arbitrarily. For example, in reconfigure:
* Don't hardwire the python executable, but
* Check that the python executable running the script is the original one (compare sys.executable with a stored value).
If there is a mismatch, print a meaningful error message telling the user to either run the script explicitly with the original python, or to set a command line flag indicating the current python is to be used (and is then a part of the reconfiguration).
Good idea. Satish, unless you can find a problem with this suggestion could you please make this change.
Speaking of meaningful error messages, the message from petsc4py.Configure.configureLibrary:
realpath of /usr/lib/libpython.dylib (/System/Library/Frameworks/Python.framework/Versions/2.6/Python) does not point to Python library path (/Library/Frameworks/Python.framework/Versions/6.1/Python) for current Python; Are you not using the Apple python?
Fixed. Barry
is misleading since the current python library path is not obliged to be /usr/lib/libpython's realpath, but can also be one of a handful of hardcoded macports pythons as well.
-David
We've had endless discussions about this. If we don't hardwire it and someone runs the reconfigure... after a path change then they get something different and get very confused. If we do hardware it then it cannot easily use a different python the way a user might think it would. We've had people screwed on both sides of this (we didn't used to hardware it).
If you have a solution distinct from those two flawed schemes we'd love to try it.
Barry
Cheers,
Andy
On Mar 29, 2011, at 11:09 PM, Matthew Knepley wrote:
On Tue, Mar 29, 2011 at 9:18 PM, Andy Aschwanden <[email protected]> wrote: Dear PETSc developers
I'm trying to install petsc-3.1-p4 with --download-petsc4py on my OSX 10.6, and get the following error:
TESTING: configureLibrary from PETSc.packages.petsc4py(config/PETSc/packages/petsc4py.py:43) ******************************************************************************* UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): ------------------------------------------------------------------------------- realpath of /usr/lib/libpython.dylib (/System/Library/Frameworks/Python.framework/Versions/2.6/Python) does not point to Python library path (/Library/Frameworks/Python.framework/Versions/6.1/Python) for current Python; Are you not using the Apple python?
Detailed configure.log is attached.
The answer to the above question is: I'm *NOT* using the Apple python, instead I have python26 installed via MacPorts. There are, however, various python installations on my system, including an EPD 6.1 in /Library/Frameworks/Python.framework/Versions/6.1/Python.
I will look at the log, but this install is no longer the easiest one. If you just install PETSc, and then use
pip install petsc4py
when you have PETSC_DIR and PETSC_ARCH defined, it should work.
Thanks,
Matt
I did $ python_select python26 to select the MacPorts python distribution I want to use with petsc4py, and indeed
$ which python /opt/local/bin/python
points to the right place. I don't know why petsc picks up the wrong python. Is there a way to tell petsc which python version it should use for petsc4py.
Thanks,
Andy
CC: David Maxwell
Dr. Andy Aschwanden ARSC Postdoctoral Fellow Geophysical Institute 903 Koyukuk Drive Fairbanks AK 99775 USA
email [email protected] phone +1 (907) 474-7199 fax +1 (907) 474-7290
-- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
Dr. Andy Aschwanden ARSC Postdoctoral Fellow Geophysical Institute 903 Koyukuk Drive Fairbanks AK 99775 USA
email [email protected] phone +1 (907) 474-7199 fax +1 (907) 474-7290