New Ticket     Tickets     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #31891 (closed defect: duplicate)

Opened 5 years ago

Last modified 18 months ago

Python loading system numpy in preference to MacPorts version (Lion)

Reported by: jamie@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: Cc: guygurari@…, ptmkenny@…, bardeau@…, russell.jones@…, ttimo@…, jwa@…, dh@…, michaelld@…, tsutterley@…, dersh@…, petr@…, larryv@…
Port: python27 py-numpy

Description (last modified by ryandesign@…) (diff)

I'm having an issue where python scripts are loading the system numpy version instead of the MacPorts compiled version, this leads to the following error message:

RuntimeError: module compiled against API version 6 but this version of numpy is 4

and in some cases (e.g. scripts that use matplotlib) causes crashes.

This has only started occurring on my system since I upgraded to OS X Lion.

The fix so far seems to be to add the following code to the top of each script before loading numpy:


but this is extremely kludgy fix, and I never had to previously do this. My PYTHONPATH variable points to my local python repository and to the MacPorts site-packages directory only. Is there somewhere else I can tell python to stop loading stuff from /System/Library/Frameworks/Python.framework?

Change History

comment:1 Changed 5 years ago by ryandesign@…

  • Description modified (diff)

comment:2 Changed 5 years ago by guygurari@…

  • Cc guygurari@… added

Cc Me!

comment:3 Changed 5 years ago by guygurari@…

Same problem here, and the workaround works for me. Thanks!

comment:4 Changed 5 years ago by jamie@…

I should add that another way to fix this issue, which I'm now using (modifying all my python scripts which are used across multiple platforms in a mission critical system is not an option for me), is to simply make the Apple installed python-2.7 the default using:

port select python python27-apple

comment:5 Changed 4 years ago by jmr@…

This is my sys.path in macports python2.7:

>>> import sys
>>> print sys.path
['', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg-info']

What is in yours? There must be some system paths if reversing it helps? Which python port are you using anyway?

comment:6 Changed 4 years ago by ptmkenny@…

I have the same issue. This is what I get:

>>> import sys
>>> print sys.path
['', '/Library/Python/2.7/site-packages/virtualenv-1.6.4-py2.7.egg', '/Library/Python/2.7/site-packages/CherryPy-3.2.2-py2.7.egg', '/Library/Python/2.7/site-packages/Mnemosyne-2.0_RC4-py2.7.egg', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC', '/Library/Python/2.7/site-packages']

comment:7 Changed 4 years ago by ptmkenny@…

  • Cc ptmkenny@… added

Cc Me!

comment:8 in reply to: ↑ description Changed 4 years ago by bardeau@…

I am experiencing the same problem for the software I am in charge (

From what I can understand, it seems that the numpy/core/ dynamic library provided by the MacPorts-numpy has been built with the numpy API version 4, while the include files it offers provide the API version 6. API (and ABI) versions can be found in numpy/core/include/numpy/_numpyconfig.h (NPY_API_VERSION and NPY_ABI_VERSION resp).

When you import numpy.core.multiarray (explicitely, or implicitely when importing numpy) from the python interpreter, there is no problem since numpy/core/ is self-consistent.

But custom C-based Python-Numpy extensions are built with those lines in particular: #include "numpy/arrayobject.h" import_array();

At load time the function "import_array" checks if the 'NPY_FEATURE_VERSION' (from NPY_API_VERSION in _numpyconfig.h) is consistent with the one numpy/core/ has been built with (see PyArray_GetNDArrayCFeatureVersion in numpy/core/code_generators/ in numpy sources). The error message comes from here.

I can also quote those few lines from doc/source/reference/c-api.array.rst: "ABI incompatibility is automatically detected in every numpy's version. API incompatibility detection was added in numpy 1.4.0. If you want to supported many different numpy versions with one extension binary, you have to build your extension with the lowest NPY_FEATURE_VERSION as possible."

So at this stage I do not why the MacPorts-numpy is inconsistent. Is this intended?

comment:9 Changed 4 years ago by bardeau@…

  • Cc bardeau@… added

Cc Me!

comment:10 Changed 4 years ago by russell.jones@…

  • Cc russell.jones@… added

Cc Me!

comment:11 Changed 3 years ago by ttimo@…

  • Cc ttimo@… added

Cc Me!

comment:12 Changed 3 years ago by ttimo@…

Would appreciate a fix for this. The workaround sys.path.reverse still works though.

comment:13 Changed 3 years ago by larryv@…

  • Cc jwa@…, dh@…, michaelld@… added

comment:14 Changed 3 years ago by macsforever2000@…

  • Port set to python27 py-numpy

comment:15 Changed 3 years ago by tsutterley@…

  • Cc tsutterley@… added

Cc Me!

comment:16 Changed 2 years ago by dersh@…

  • Cc dersh@… added

Cc Me!

comment:17 Changed 23 months ago by petr@…

  • Cc petr@… added

Cc Me!

comment:18 Changed 20 months ago by petr@…

There is nothing py-numpy-specific with this problem, right? It is just about which site-packages have precedence, or that MP's version does not have it for Python 2.7.

comment:19 Changed 20 months ago by petr@…

If I understand things correctly, the problem observed here is basically a symptom, due to bug/feature as in ticket #34763.

comment:20 Changed 20 months ago by larryv@…

  • Cc larryv@… added

The likely cause has been fixed in r126840. Could someone verify that it solves this issue?

comment:21 Changed 18 months ago by jmr@…

  • Status changed from new to closed
  • Resolution set to duplicate

No response; assuming this was the same issue.

Note: See TracTickets for help on using tickets.