search

FlorianRhiem / pyGLFW

Python bindings for GLFW
MIT License
233 stars 36 forks source link

Potential issues with package binaries on Linux #45

Closed almarklein closed 4 years ago

almarklein commented 4 years ago

I meant to test out the latest version on Linux (Ubuntu 19.10), because I suspected there might be an issue on Wayland, but ran into an issue. pip install glfw will take the tar.gz instead of the wheel. Pointing pip directly at the wheel gives me glfw-1.10.1-py2.py3-none-manylinux2010_x86_64.whl is not a supported wheel on this platform. So it looks like there's a flag somewhere there that prevents it from being used. I tried with pip 18.x and 20.0.1. Have you looked at auditwheel to verify/repair these wheels?

edit: the below turns out not to be an issue I could therefore not test the potential issue I was looking into, so I'll just describe it. I can have a look later if needed. If the binary glfw lib that comes packaged is preferred over the system library, it will probably fail on Wayland (because it needs a differently compiled lib). The user can of course use PYGLFW_LIBRARY but that's annoying.

The README says that you can use the system library by installing it, but library.py seems to prefer the packaged lib instead, but I may be wrong here.

None of these are pressing issues, BTW :)

FlorianRhiem commented 4 years ago

The issue seems to be with the wheel tags, as those only seem to support specific python versions and not py3 when manylinux2010 is used (py3-none-any and py36-none-manylinux2010_x86_64 both work). I think those used to be supported, but I'll have to look into this. If they don't work, I might have to use something like py2.py27.py3.py30.py31.py32.py33.py34.py35.py36.py37.py38 which would be more than a little silly...

The wheels are not pure manylinux2010 wheels as glfw requires more X11 libraries than manylinux2010 provides. See this issue for a discussion about that. As I don't think providing an alternative/supplementary set of X11 libraries is a good idea (due to the potential for conflicts and weird, hard-to-debug issues), the wheels do not provide these X11 libraries. This means that, when the wheels are installed, the included GLFW library might not be usable. In that case the user can either install the missing X11 libraries, install the system GLFW (which will most likely provide the missing X11 libraries as well) or install GLFW from source (which will also mean that they'll install the missing X11 libraries).

On Linux, each library that is found is loaded in a subprocess and its version is queried. Then, the library with the largest version tuple is used. If a library cannot be loaded, it is not considered further, as it cannot be used anyway. The search path order only becomes relevant if several package provide the exact same largest version tuple. As a result, the packaged library should not cause any problems if they cannot be loaded. So the second issue you're describing should not occur. If this does not work as intended, please let me know!

FlorianRhiem commented 4 years ago

Yes, this used to work in pip 19.3.1, it's probably related to this issue and this issue, which were caused by the switch from pip-internal tags to packaging tags, that seems to have broken plenty of binary wheels. I'll have to see whether this is something they plan to fix or whether I'll have to go with that silly wheel name instead.

almarklein commented 4 years ago

We're facing similar problems (https://github.com/pypa/pip/issues/7636).

On Linux, each library that is found is loaded in a subprocess and its version is queried. Then, the library with the largest version tuple is used. If a library cannot be loaded, it is not considered further, as it cannot be used anyway.

Ah, I've missed that. That's great! 👍

FlorianRhiem commented 4 years ago

The issue seems to be fixed in master of pypa/packaging, but until that's released and used by pip the silly wheel name will have to do. I've uploaded the additional wheels to PyPI and I hope they will be used now. At least on Ubuntu:19.04 it works.

The included library might not work with Wayland, however, as I'm building them on a fairly minimal system (the manylinux2010 image with additional libXinerama, libXrandr, libXcursor and libXi). As a result, Wayland support will be missing. As the version tuples of the two libraries will be equal, the search path order might actually cause a problem in this case and PYGLFW_LIBRARY might have to be used. It'd be great if you could test this to confirm that this problem occurs. If it does, I'll have to think about reordering the search paths or finding an alternative solution.

Edit: the problem I'm describing would be on a system that has the required X11 libraries installed, but uses Wayland. A system without the X11 libraries listed above would not be able to load the packaged library.

almarklein commented 4 years ago
FlorianRhiem commented 4 years ago

Thank you for testing this!

That's how it should work. Of course it'd be ideal if it would work out-of-the-box on wayland, too, but I'll open a new issue for that.

almarklein commented 4 years ago

For reference: #46