Support fixing top-level extension modules #72
Comments
|
In our project, we work around it by running the following script: #!/bin/sh
set -ex
cd $(mktemp -d)
unzip $abspath_to_wheel
delocate-path -L $package_name.dylibs .
wheel=$(basename $abspath_to_wheel)
zip -r $wheel *
mkdir -p $output_dir
mv $wheel $output_dir
tempdir=$(pwd)
cd -
rm -rf $tempdirThe actual setup is available at McSinyx/palace@5406740. Thank you for providing the lower-level utility for hacks like this to be possible, though I still think it'd be nice if this is supported by |
I'd love too, since it turns out the work-around script I posted above had trouble relinking
It'd be an honor, although I can't promise about the timing since I've just (physically) got back to school this week and they're bombarding us with 6h of lectures everyday for 6 days a week. What I mean is please don't wait for me if you (or any other) figure out how to do it properly, although I'll try my best coordinating my time to help. |
|
This is currently preventing bundling from properly occurring with And with 170k downstream deps, I highly doubt the PyYAML maintainers are going to be interested in the "just change your package layout" solution. Considering manually putting the output paths from |
|
I'm in the same boat as @bsolomon1124 and I ended up using this fork: https://github.com/Chia-Network/delocate/commits/master which merged #39 and adds a (force) file insertion option. Since this seems to work (and builds macos wheels with the right bundled libs directory) I'm wondering what's still holding this up? If I actually had a Mac I would certainly poke at this more and make sure the tests work, etc, but I don't have a Mac (or any "extra" time for that matter). Thanks! (my example is here: https://github.com/freepn/py-re2/actions/runs/487166636) |
MRG: Allow for delocating top level modules. This delocates libraries into one directory per wheel. I've added a top-level package-less wheel to test with. Prevents copying duplicate libraries when a wheel has multiple packages. Fixes #35. Fixes issues where the module to work on is at the top-level, such as a wheel with no packages. Generally any current issue where delocate mysteriously doesn't bundle libraries has been fixed. Fixes #72, fixes #22, fixes #45, fixes #63, fixes #121, fixes #66, fixes #49, fixes #67. See `_decide_dylib_bundle_directory` for how the folder to use is determined. I've followed the advice from #72 to use an auditwheel-style name. Wheels without packages use the folder `{package_name}.dylibs`, wheels with packages will put a `.dylibs` folder in only one of the packages preferring the one that matches the wheel name. The one directory will hold the dependencies of the entire wheel. After that the fix was simple: In `delocate_wheel` call `delocate_path` only once and call it with a `tree_path` that includes the entire wheel. Since this always collects everything regardless of if a package is found or not. This will also resolve issues where namespace packages couldn't be delocated. Fixes #95.
Potential duplication of GH-12, GH-15, GH-22, GH-45, GH-63 and possibly many others. I open this to discuss the strategy to fix this quite common issue.
Rationale
delocate-listdepsworks perfectly for these wheels, whiledelocate-wheelfails silently. This is really confusing to the users. It'd be a lot better if any detected missing lib can be added to the wheel.Proposal
auditwheelsupport top-level extension modules by copying the shared libraries to{package-name}.libsand I suggestdelocatefollow that convention. Withpackage-namebeing canonicalized tosnake_case, this should never cause name collision with the package ending withlibs. For exampleI'm looking forward to see your response on this. Happy labor day BTW 🎆
The text was updated successfully, but these errors were encountered: