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