In article <cajv6ndphginodqq1fkh1-ubcyzq2chag7qjxsbq0_pht5z8...@mail.gmail.com>, Matthew Taylor <m...@numenta.org> wrote: > 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.
Just taking a quick look at your setup.py there shows a quite complicated build, including SWIG. One suggestion: keep in mind that it's normal on OS X for the absolute path of shared libraries and frameworks to be embedded in the linked binaries, including the C (or C++) extension module bundles (.so files) built for Python packages. If any of the .so files or any other binary artifacts (executables, shared libraries) created by your package are linked to the Python interpreter's shared library, that may be why you are getting a mixture of Python instances. One way to check for this is to use: otool -L *.so *.dylib on all of the directories containing linked binaries in your project and check for paths like: /System/Library/Frameworks/Python.framework That would be a link to the Apple-supplied system Python. A link to /Library/Frameworks/Python.framework or some other path would be to a third-party Python like from python.org or Homebrew. Due to differences in how the various Pythons are built and depending on what the C or C++ code is doing, it may not be possible to have one binary wheel that works with different Python instances of the same version. For many simple projects, it does work. You *could* also ask on the PythonMac SIG list. https://mail.python.org/mailman/listinfo/pythonmac-sig -- Ned Deily, n...@acm.org -- https://mail.python.org/mailman/listinfo/python-list
