building c extensions with setuptools that are not tied to python installed on build machine

Matthew Taylor matt at numenta.org
Tue Feb 10 19:17:48 EST 2015


Hello pythonistas,

This is my first message to this mailing list, so if my question is
off-topic, please direct me to the correct mailing list.

I manage the NuPIC [1] open source machine intelligence project, which
is a python project with C extensions. We have a build on Travis-CI
[2] that creates binary wheels on release tags (in git). I'm having a
problem with OS X binaries.

The Travis-CI build machine is OS X 10.9 and uses the default Python
2.7.6 that comes with OS X. When binaries are created on this machine,
they seem to be linked somehow to the default Python, because when a
user running a homebrew-installed python (or Anaconda) attempts to
install the binary, there's an awful problem [3], even when the Python
versions are exactly the same (2.7.6). It seems that some connection
is made at compile time when C extensions are built that link the
binary file to the system Python on the OS X machine building the
binary. This means any users working with the homebrew Python or
Anaconda will get nasty thread errors when the program attempts to run
against two Pythons.

    Fatal Python error: PyThreadState_Get: no current thread

Does this make sense to anyone? I'm still a little new to Python in
general (especially binary packaging), and it seems like this would be
a common problem for any projects with C extensions that need broad
binary distribution. Does anyone have any suggestions? Please take a
look at our setup.py file [4] and tell me if we're doing something
egregiously wrong.

[1] https://github.com/numenta/nupic
[2] https://travis-ci.org/numenta/nupic
[3] https://github.com/numenta/nupic/issues/1813
[4] https://github.com/numenta/nupic/blob/master/setup.py

Thanks thanks in advance,
---------
Matt Taylor
OS Community Flag-Bearer
Numenta



More information about the Python-list mailing list