I have created wheels that work for 7.0, but are broken for 8.0 because the way that the __init__.py in the mosek ctypes python shim imports has changed for the worse. The relevant code is in this gist since it doesn't appear in this lib. The code for mosek 7.0 is in this gist
Currently, it tries to write the variable __mosekinstpath__ to a python file that is written by the setup.py in this repo, and that path is a bunch of garbage if one runs
python setup.py bdist_wheel
The resultant wheel has all the right shared objects and python files, but it will fail on import mosek as it tries to load the shared objects from the wrong (nonexistant) directory that it tried to sniff out on creation.
The upshot is that the loadmosek code should do the same thing as the code in Mosek 7.0: it should try checking the directory of the __init__.py
Take a look at how numpy handles this for the native shared objects distributed as a part of numpy wheels.
Furthermore, this is the only problem preventing wheels from being created!
I recommend you all look into constructing the right metadata so that wheels are platformed, and distribute the wheels themselves instead of this pkg that generates them.
The code solution to this I can see is to just adjust the loading code in __init__.py to work only with wheels and just distribute wheels.
@ulfworsoe what do you think? Since some code is dynamically pulled down I can't attach a patch directly
Hi,
I have created wheels that work for 7.0, but are broken for 8.0 because the way that the
__init__.py
in the mosek ctypes python shim imports has changed for the worse. The relevant code is in this gist since it doesn't appear in this lib. The code for mosek 7.0 is in this gistCurrently, it tries to write the variable
__mosekinstpath__
to a python file that is written by the setup.py in this repo, and that path is a bunch of garbage if one runspython setup.py bdist_wheel
The resultant wheel has all the right shared objects and python files, but it will fail on
import mosek
as it tries to load the shared objects from the wrong (nonexistant) directory that it tried to sniff out on creation.The upshot is that the
loadmosek
code should do the same thing as the code in Mosek 7.0: it should try checking the directory of the__init__.py
Take a look at how numpy handles this for the native shared objects distributed as a part of numpy wheels.
Furthermore, this is the only problem preventing wheels from being created!
I recommend you all look into constructing the right metadata so that wheels are platformed, and distribute the wheels themselves instead of this pkg that generates them.
The code solution to this I can see is to just adjust the loading code in
__init__.py
to work only with wheels and just distribute wheels.@ulfworsoe what do you think? Since some code is dynamically pulled down I can't attach a patch directly