8000 [Bug]: Unit tests: MacOS 14 failures: gi-invoke-error-quark · Issue #29732 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]
Skip to content

[Bug]: Unit tests: MacOS 14 failures: gi-invoke-error-quark #29732

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
jayaddison opened this issue Mar 11, 2025 · 13 comments · Fixed by #29734
Open

[Bug]: Unit tests: MacOS 14 failures: gi-invoke-error-quark #29732

jayaddison opened this issue Mar 11, 2025 · 13 comments · Fixed by #29734

Comments

@jayaddison
Copy link
Contributor
jayaddison commented Mar 11, 2025 •
edited
Loading

Bug summary

During a recent GitHub Actions workflow for unrelated pull request #29721, the following error appeared:

E           gi._error.GError: gi-invoke-error-quark: Could not locate g_option_error_quark: dlopen(libglib-2.0.0.dylib, 0x0009): tried: 'libglib-2.0.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OSlibglib-2.0.0.dylib' (no such file), '/usr/lib/libglib-2.0.0.dylib' (no such file, not in dyld cache), 'libglib-2.0.0.dylib' (no such file) (1)

Code for reproduction

This occurred for Python3.12 and Python3.13 on MacOS 14:

Actual outcome

See the error in the main description and linked build logs.

Expected outcome

The tests should pass as expected (the error appears to be a transient failure to locate/load a dynamic library file).

Additional information

N/A

Operating system

MacOS 14

Matplotlib Version

86fd11f

Matplotlib Backend

N/A

Python version

No response

Jupyter version

N/A

Installation

None

Edit: remove code-block markup surrounding non-code details
Edit: the failure appears to occur fairly reliably, so remove the description of it as transient
@jayaddison jayaddison mentioned this issue Mar 11, 2025
Merged
5 tasks
@jayaddison
Copy link
Contributor Author

I think that the libglib-2.0.0.dylib linked library file that appears to be missing (dlopen fails to find it) should be provided by the glib Homebrew package, pulled in as a dependency of ffmpeg.

Version 2.84.0 of glib was installed during both failed tests reported by this bug -- meanwhile, version 2.82.5 of glib was installed during one of the recent successful MacOS 14 pipelines on the mainline branch.

A next step could be to confirm whether the library file was included in the updated Brew package -- and if so, whether it was on the library load search path.

@jayaddison
Copy link
Contributor Author
jayaddison commented Mar 11, 2025 •
edited
Loading

I think that the libglib-2.0.0.dylib linked library file that appears to be missing (dlopen fails to find it) should be provided by the glib Homebrew package, pulled in as a dependency of ffmpeg.

Hmm.. an earlier error hints at PyGObject as potentially more relevant:

gi._error.GError: gi-invoke-error-quark: Could not locate g_option_error_quark: dlopen(libglib-2.0.0.dylib, 0x0009): tried: 'libglib-2.0.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OSlibglib-2.0.0.dylib' (no such file), '/usr/lib/libglib-2.0.0.dylib' (no such file, not in dyld cache), 'libglib-2.0.0.dylib' (no such file) (1)
PyGObject 4 is not available

(contrastingly, that message does not appear during the successful build - there we find PyGObject 4 is available instead)

I think this may be something to do with a recent dependency version upgrade taking place in GObject>=3.51:

I plan to open an experimental pull request to place an upper limit on the PyGObject package version installed during GitHub Actions unit testing, to learn whether that could (temporarily) resolve the issue.

@jayaddison jayaddison mentioned this issue Mar 11, 2025
Merged
5 tasks
@jayaddison
Copy link
Contributor Author

I think this may be something to do with a recent dependency version upgrade taking place in GObject>=3.51:

Pull request #29734 seems to support that theory; pinning PyGObject<3.52.0 allows the GitHub Actions tests.yml workflows to succeed for MacOS 14 (both with py3.12 and also with py3.13).

@jayaddison

This comment has been minimized.

Sign in to view
@jayaddison

This comment has been minimized.

Sign in to view
@jayaddison jayaddison changed the title [Bug]: Unit tests: transient MacOS 14 failures: gi-invoke-error-quark [Bug]: Unit tests: MacOS 14 failures: gi-invoke-error-quark Mar 12, 2025
@jayaddison
Copy link
Contributor Author

@dstansby @timhoffm thanks again - I hope to figure out where this problem originates, so that we can remove the temporary version limit in the not-too-distant future; my guess is that there'll be a bug to report in GNOME's pygobject project, but I'm not certain yet.

@dstansby
Copy link
Member

Fab, thanks for following up! I'll re-open this issue so we don't forget.

@dstansby dstansby reopened this Mar 12, 2025
This was referenced Mar 13, 2025
Closed
Closed
@jayaddison
Copy link
Contributor Author

By removing the Homebrew-provided gobject-introspection library as part of #29777, some progress appears to be made; a different and I think deeper dependency layer of cairo is next up to fail to resolve:

ImportError: Typelib file for namespace 'cairo', version '1.0' not found
PyGObject 4 is not available

I'd intended for solely the Homebrew-installed cairo to be provided, negating any requirement for a PyPI/pip-based install -- but it seems that pycairo was also retrieved from the Python package index:

Collecting pycairo>=1.16 (from PyGObject)
  Using cached pycairo-1.27.0-cp313-cp313-macosx_14_0_arm64.whl

I'm not sure what to do next, yet.

@jayaddison
Copy link
Contributor Author

Note also: cairo (a linkable binary library) and py3cairo (Python bindings to that library) appear as distinct packages in Homebrew.

@jayaddison
Copy link
Contributor Author

I am struggling to get PR #29777 to resolve this currently, and would be glad for help.

I think that there may be an incompatibility between recent versions of PyGObject as distributed on PyPI and the cairo and pycairo bindings available from either PyPI or Homebrew -- but I don't really understand the problem loading the cairo linked library yet.

I do note that Homebrew plans to update their own packaged version of PyGObject in the near future; so one option, if acceptable, could be to install from that instead of using pip install - either as a temporary solution until the interfaces restabilize, or longer-term if it is OK to migrate more CI dependencies to use Homebrew. The relevant Homebrew PR is: Homebrew/homebrew-core#210911

(it is currently blocked by the fact that freedesktop.org is temporarily down for some planned maintenance as they migrate to another infrastructure hosting provider)

@jayaddison
Copy link
Contributor Author

As a recap / status update:

This was referenced Mar 28, 2025
Open
Merged
@jayaddison
Copy link
Contributor Author

Some notes/suggestions from discussion:

  • The gobject-introspection Homebrew package should be the one providing the Cairo typelib.
  • It may be worth comparing the results when using Homebrew's Python package instead of the one installed using setup-actions/python.

I'm going to try to step away from the problem until early next week, because I think I've been getting stuck in various potentially-irrelevant details and reconsidering it from fresh may help.

@huwjenkins huwjenkins mentioned this issue Apr 14, 2025
Open
@jayaddison
Copy link
Contributor Author

(I haven't yet gotten around to that testing - I hope to soon, but I'm not sure exactly when it'll be)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
2 participants
@dstansby @jayaddison
0