Compatibility with github's CI Mac OS X runner images

[HinTak]

Sorry for filing it here - I suspect this discussion might belong to github's actions/runner-images repo, rather than here. That said, I have a curious issue trying to use glfw inside github's own CI action against its mac os x runners. What I have is something like this:

    if not glfw.init():
        raise RuntimeError('glfw.init() failed')
    glfw.window_hint(glfw.VISIBLE, glfw.FALSE)   # with or without this line
    glfw.window_hint(glfw.STENCIL_BITS, 8)
    window = glfw.create_window(640, 480, '', None, None)
    assert window is not None
    glfw.make_context_current(window)

    print(glGetString(GL_VERSION))

On linux and on user's mac os x desktop, this gives something normal and carry on. But within github's CI, against the mac os x hosts (only those; I think it also doesn't work for windows, but that's a different issue), this gives a nullptr for GL_VERSION, and also GLFWError: (65545) b'NSGL: Failed to find a suitable pixel format'. So my first question is, are there people using glfw on github's CI against mac os x runners successfully?

The background of this is kyamagu/skia-python#214 , but at this point somewhat unrelated - I was trying to use github's CI to replicate a mac user's desktop issue (since I am on Linux only), but github's CI behaves entirely differently from user's mac desktop, so now I have two separate issues.

[FlorianRhiem]

Hey @HinTak,

in the past, I've had issues in macOS requiring me to set some more window hints (e.g. setting the version to 3.3, core profile and setting the forward compatibility flag), so that might be something worth trying. The error message you get is produced nsgl_context.m and the code above which assembles the attribs includes some checks for the context version, samples, etc, so perhaps try being specific with the context and framebuffer flags and perhaps vary them a bit.

Some more generic suggestions:

• What GLFW library are you using? It might be worth a try to use one downloaded from https://www.glfw.org/download.html as the pyGLFW wheels currently provide GLFW 3.3 binaries instead of 3.4 as I'm still working on getting 3.4 to build on the manylinux images used for Python wheels. Perhaps this is a bug fixed in 3.4, so downloading that binary and setting PYGLFW_LIBRARY to the path of the library might help.
• Have you tried compiling and running a minimal C program that does the same thing, just to see if that works? If it also fails, that means the issue lies with GLFW itself (and of course the CI system) and not this wrapper.

[HinTak]

@FlorianRhiem Thanks for the quick response!

This is all within github's CI system: https://github.com/kyamagu/skia-python/blob/e0b030c14e33f70880cfcc502eaeed898a77fc3c/.github/workflows/ci.yml#L127 ( I am trying to add glfw to the MAC OS X line below, which is missing it from ages ago). It seems to be downloading a file called glfw-2.7.0-py2.py27.py3.py30.py31.py32.py33.py34.py35.py36.py37.py38-none-macosx_10_6_intel.whl via pip. It says it is downloading (97 kB) - that sounds way too small to have a bundled GLFW? - I did suspect that maybe it is picking up something strange from say, macport (with a glfw linked against Xquartz?). I'll need to investigate. Is it possible to query from within pyglfw where the location it is loading glfw from? I really only have the CI logs to work with, after I send in different changes and getting the logs back. But of course I can add a "ls -lR" to the CI run commands and see what it returns...

This issue seems to be specific to github CI (and have been the same for possibly 4 years); desktop mac os x users don't seem to have this problem (they have something else unrelated to glfw I think).

I have looked around and saw the tips about mac os needing core profile, etc, and have an extended version of the python code like below, but this does not improve things:

    if not glfw.init():
        raise RuntimeError('glfw.init() failed')
    glfw.window_hint(glfw.VISIBLE, glfw.FALSE)
    glfw.window_hint(glfw.STENCIL_BITS, 8)
    # See https://www.glfw.org/faq#macos
    glfw.window_hint(glfw.CONTEXT_VERSION_MAJOR, 3)
    glfw.window_hint(glfw.CONTEXT_VERSION_MINOR, 2)
    glfw.window_hint(glfw.OPENGL_FORWARD_COMPAT, True)
    glfw.window_hint(glfw.OPENGL_PROFILE, glfw.OPENGL_CORE_PROFILE)
    window = glfw.create_window(640, 480, '', None, None)
    assert window is not None
    glfw.make_context_current(window)

I'll possibly try to poke around and see what' that 97K wheel is made of. Thanks.

[FlorianRhiem]

You can print glfw._glfw to see the actual library that was loaded. Try using a binary downloaded from https://www.glfw.org/download.html or one built on that system.

The macOS binary is only 77kB zipped all by itself, so that wheel size looks about right.

[HinTak]

The 97k wheel seems to match the description at the bottom of:
https://pypi.org/project/glfw/#files
and on mac os x 14 (which is arm64 based) it gets a 94k wheel which matches the other one too.

[HinTak]

Thanks a lot. The glfw._glfw tips is useful to know. I'll add that to pytest and see what it says...

[HinTak]

@FlorianRhiem I forgot to mention that using glut directly works as expected against github CI's mac os x action runners. So this is something specific to the github CI + mac os x + glfw/pyglfw combo. Changing any of the 3 (desktop mac os, Linux, or glut) gives a working setup. At the moment I am leaning towards something strange on github CI. It may have a libglfw from mac port, for example. I need to poke it a bit.

[HinTak]

The libglfw being used is

'/private/var/folders/n8/w901w1rn4ldg6yskstndsj200000gn/T/cibw-run-sngkcv1e/cp311-macosx_x86_64/venv-test/lib/python3.11/site-packages/glfw/libglfw.3.dylib', handle 208be2e20 at 0x10c6fe5d0>

That seems to be the package bundled one. So needs to keep looking...

[FlorianRhiem]

As suggested before, It might be worth a try to use one downloaded from https://www.glfw.org/download.html as the pyGLFW wheels currently provide GLFW 3.3 binaries instead of 3.4. Perhaps this is a bug fixed in 3.4, so downloading that binary and setting PYGLFW_LIBRARY to the path of the library might help.

[HinTak]

I have downloaded 3.4 binary, bundled it in the sample repo, adding the print glfw._glfw to verify that it is using the downloaded binary, and it is still failing. The code is at:
https://github.com/HinTak/skia-python-examples/blob/8d123f3b996577126b407390164381a14acf7dc8/.github/workflows/ci.yml#L26

Note that it passes the sdl2 and the glut python lines, so those two don't seem to have a problem getting a GL context inside github's CI. If you want to experiment, I think you can just modify the top of the CI line to do so on "pull", and create a pull on that repo, and it would run on pull.

[HinTak]

I have made a test case and filed upstream: glfw/glfw#2570