I really don't like Python packaging. 2 days and c...
# random
b
I really don't like Python packaging. 2 days and counting trying to package some C++ into a whl and still hitting link issues when loading it 🄓
šŸ¤• 3
If anyone is feeling generous and wants to lend a bone, I can't seem to find the extremely magical incantation to include additional
.so
objects in my
whl
and have them be loaded as well. This post: https://stackoverflow.com/questions/63804883/including-and-distributing-third-party-libraries-with-a-python-c-extension sounds like it's possible, but sadly
package_data
doesn't seem to be adding the relevant `.so`s
b
Yeah I'm sitting in a chroot just trying various settings but
package_data
each incantation bears no fruit
I'm guessing my dir structure is what's to blame, but can't figure out what setuptools is expecting. The silent failures to find any files kills me
I finally got the `.so`s in the wheel. you need
packages=...
in order to use
package_data
šŸ™„
šŸ‘€ 1
Now to find the linker incantation so that
ldd
shows the dynamic deps
I'm getting some objects loaded and some not šŸ™ˆ so close
Copy code
ldd path/to/my/library.so
        libwhatever-base.so => ...
        libwhatever-tree.so => not found
--no-as-needed
I could cry. It's finally working
ā¤ļø 1
šŸš€ 2
What PITA Python packageing is
😿 2
For the record: • Package data is only consumed if you explicitly have a package. A Cext isn't a package • Link flags can just be ignored by the linker • And linking is hard, especially when hidden behind setuptools • Relative load paths are a thing