5

We are currently running our own private PyPi server, and uploading wheels of our internal Python libraries to speed up installs.

Many of our tools require numpy, scipy, pandas, etc.

We built wheels for all of our dependencies by installing all of our dependencies from source, and then using 

pip wheel .

which outputs wheels for all of our dependencies - or so we thought.

We have found that when we install, say, numpy from our private PyPi, where it is available as a wheel, the following happens.

>>> import numpy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "redacted/lib/python2.7/site-packages/numpy/__init__.py", line 199, in <module>
    from . import random
  File "redacted/site-packages/numpy/random/__init__.py", line 99, in <module>
    from .mtrand import *
ImportError: redacted/lib/python2.7/site-packages/numpy/random/mtrand.so: undefined symbol: PyFPE_jbuf

It is clear to me that these wheels were not created properly. What is not clear to me is how to go around fixing this. We are not distributing these to the public, only for our internal tools.

dacox
  • 502
  • 1
  • 6
  • 14

1 Answers1

0

I am far from being an expert on wheel packaging but here is what I know about wheel building so far.

For OS X and Windows you can build binary wheels and use the to deploy your software.

On Linux this process doesn't always work and that's because many binary wheels will try to use specific versions of OS libraries (.so) and these are different from one distribution to another, or even inside the same distribution.

Here is some further reference:

sorin
  • 161,544
  • 178
  • 535
  • 806