Skip to content
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.

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

Import issues with 1.7.0 #179

Open
opoplawski opened this issue Jan 12, 2025 · 11 comments
Open

Import issues with 1.7.0 #179

opoplawski opened this issue Jan 12, 2025 · 11 comments

Comments

@opoplawski
Copy link

I'll note that I know nothing about Python FFI interfaces. I'm looking at updating the Fedora python-xcffib package to 1.7.0. This is now building with gcc and making an arch dependent package. When I try to then build cairoffi, it fails with:

../BUILDROOT/usr/lib/python3.13/site-packages/cairocffi/__init__.py:18: in <module>
    from .ffi import ffi
../BUILDROOT/usr/lib/python3.13/site-packages/cairocffi/ffi.py:26: in <module>
    ffi.include(xcb_ffi)
/usr/lib64/python3.13/site-packages/cffi/api.py:527: in include
    raise TypeError("ffi.include() expects an argument that is also of"
E   TypeError: ffi.include() expects an argument that is also of type cffi.FFI, not 'FFI'

Do you know what is going on here? Does cairoffi need to be updated or is xcffib doing something strange? Thanks.

@tych0
Copy link
Owner

tych0 commented Jan 12, 2025

hmm. cc @georgeharker.

Can you print the type of xcb_ffi there? We clearly broke something with the 1.7 release, but it's not obvious what...

@georgeharker
Copy link
Contributor

Yes, I'll look into that, I suspect this is to do with how cairo sub includes xcffib as part of it's own cffi - I have pending changes of a similar form for cairocffi.

@georgeharker
Copy link
Contributor

This is because cairo imports xcffib and builds on it as part of its cffi, when xcffib is in api mode, cairo can't sub include it without similar treatment. I'll work with them to get that sorted. I have a similar pangocffi change pending.

@tych0
Copy link
Owner

tych0 commented Jan 12, 2025

Does cffi expose some metadata about what mode it was compiled in?

@tych0
Copy link
Owner

tych0 commented Jan 12, 2025

I wonder if we should revert until cairocffi's changes land?

@georgeharker
Copy link
Contributor

I'm not sure other than the type being different - that's an unfortunate unforseen side effect as I was developing all 4 patches at the same time. It's not totally trivial to fix aside from reverting to abi mode, which would mean disabling the compiler part of the install.

I'd love to get the corresponding fixes into cairocffi and pango

@georgeharker
Copy link
Contributor

I'm wondering that too. I'll try and get in touch directly with @Kozea

@tych0
Copy link
Owner

tych0 commented Jan 13, 2025

hmm. based on the discussion in that thread, seems like we should revert for now, since the path forward is unclear and not likely to be quick.

@georgeharker
Copy link
Contributor

I agree. I may suggest an optional api mode over at Cairo with an env var for install, and I'll see if I can figure out a way to make that work offline.

tych0 added a commit that referenced this issue Jan 13, 2025
This reverts commit fb83a36.

This fanciness unfortunately does not work transparently to library
consumers like cairocffi, so they will need some patches to understand this
before we can release with it. This "fixes" github issue #179, but I'm
going to leave it open so we can have the discussion about how to fix it
there.
@tych0
Copy link
Owner

tych0 commented Jan 13, 2025

Ok, I went ahead and released 1.7.1 with the revert; I've left this issue open so we can figure out what to do using it as a place for discussion.

@georgeharker
Copy link
Contributor

Thanks and again appreciate your efforts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants