-
-
Notifications
You must be signed in to change notification settings - Fork 259
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
Feature: Don't copy dependencies' DLLs by default #2038
Comments
I disagree, you'd ship broken wheels to users.
You can already do that by passing |
I'm not saying that it should succeed in that case. It should fail the build, with something like: "X depends on shared library Y. To copy it into the python wheel, configure your build with [setting]." |
That's #2039, so closing this in favor of that. |
No, #2039 is just to add logging, it says nothing about failing the build. |
It will fail if you don't have |
Yeah, that's not a very reliable system. What if patchelf was installed for something else? "Just uninstall patchelf to avoid accidentally copying things into your build results" is such a hack. 😞 |
As I have said, you have |
Are there docs that I should have read that say "use these options to keep from copying shared libraries into your package"? Because I missed them. And I never would have guessed that from either of those options names. 😅 |
There are some docs in https://www.maturin.rs/distribution#build-wheels but definitely can be improved (esp. for people not familiar with auditwheel). |
Aha! Thanks for the pointer. I'm not familiar with auditwheel.
However, I tried both of your suggestions:
So now I'm accidentally distributing a wheel that might not work on users' systems. What I really want is:
|
That sounds reasnable, I think we can extend
|
@NfNitLoop What do you think of #2038 (comment) under this proposal, you will use |
Love it! That would be great! BTW, I assume you might make |
Can we re-open this issue, then? |
Though the current state is the least surprising behavior for Python users. |
Closing in favor of #2045 |
Existing Functionality
If I'm understanding things correctly, Maturin has this current feature:
If a build results in code that dynamically links to a library (that's not libc?), Maturin:
patchelf
to fix DLL loading (to use those copied DLLs, I assume).Example
maturin build
output:The Problem
This is really surprising behavior!
My builds had been working fine, until I added some dependency which (somewhere down the transitive dependency chain) introduces dynamic linkage. Then I got surprise errors about
patchelf
, which wasn't needed before.Thankfully I took some time to investigate the sudden need for patchelf because I don't want third-party dynamic libraries copied into my python package. It's only an accident of the dependencies I've added.
IANAL but can't there also be legal implications to distributing a DLL vs linking to it?
Requested Improvement
Maybe maturin shouldn't copy DLLs by default. Or, at a minimum, I'd love an option to explicitly disable copying them.
If some people want to allow some DLLs but avoid accidentally including others, maybe an "allow list" for DLLs to be copied would work better for them.
Workaround
For now, I'm working to remove the DLL from my dependency tree. I'm recommending that my team not add the
patchelf
dependency to our build dependencies/environments, so that it can act as a stopper to keep us from getting into this situation again.But relying on some dependency being missing is not the most stable way to accomplish this. 😅
Context
This is related to an issue I asked for help with in Discord.
The text was updated successfully, but these errors were encountered: