-
Notifications
You must be signed in to change notification settings - Fork 783
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
ABI3-like for non-extension-module
#2901
Comments
Have you tried whether the existing Or this is just about the DSO that the resulting binary tries to load being too specific? (If so, we should probably just make the existing features control the DSO name as well.) |
I didn't try but with ABI3 it said "can't locate libpython3.9.so" or something |
So I think the issue is the DSO name. Just to confirm, could you symlink the newer library to old name and check that everything else works? Thanks. |
That would be funny if that works haha, I'll test it later today when I can. |
Btw., I think you might already be able to change the DSO name by setting the |
When changing So, I changed I check by deleting that symlink and making one to This isn't a usable solution for end users but if this gets patched then I would love to use PyO3 for more! Managing Python subprocesses and communicating via stdin/stdout is terrible. |
My ideal solution would be for PyO3 to look through A possibly better solution be to prefer the same Python version as it does now, and if it can't load the file then look at the first interpreter it finds in |
I think embedding Python is not so much about finding the I think we should try to adjust the DSO name based on the As a somewhat orthogonal approach, you might want to consider using PyOxidizer to embed Python into your binary which simplifies things a lot if you do not need integration with the system-provided Python installation. |
If I recall correctly, this is a good summary of why we didn't support the Note that even if the above linking worked, if you user tried to use an older Python's libpython you risk crashes at load time with missing symbols, which is not the greatest UX. cc @encukou - as CPython's stable API maintainer, have you got any comment on what to do when a user wants to embed support for multiple Python 3 versions via the stable API? |
I'm afraid I can't do much from the CPython side. CPython builds and installs |
I'm just using Ubuntu 22.10... it comes with a minimal install of Python 3.10 and I'm using the deadsnakes PPA to install older Python versions. |
Can this be avoided by linking with the oldest version you want to support? So 3.7 in my case. |
I don't think that will give you forward compatibility because when your binary links against |
Yes but it was established that deleting the file and making a sim link to another version works. Using abi3-p37 + linking with Python 3.7 should prevent missing symbols, I hope at least in theory. |
I also wouldn't mind being able to link multiple interpreters, basically requiring the system compiling for production to have 3.7, 3.8, 3.9, 3.10 etc if it's a viable solution. As long as one binary can support multiple Python versions and only one is required client-side. |
@VirxEC Did you end up finding a solution. I have a similar issue for our software that we ship on windows, linux (aarch64, x86, armhfv7), macos. I just want to be able to use whatever interpreter is on the system if it is at least 3.7 or 3.8. I just tried on windows and I got an error that it could not find I had the idea of allowing the user to download python inside the app, but I still can't figure out if I am going to be able to lazy load it correctly after its been downloaded. There might be something to do with the libloading crate... |
@Sytten Unfortunately the current solution is not using PyO3. I would love to but I haven't found any proper solution with it. Right now I just searches the user system for Python, and the user through setting the stuff up in the GUI (for a further example, creating the virtual environment after letting the user select the python they want to use if they have multiple.) |
Description
I'd like for non-
extension-module
builds to be able to use newer Python interpreters, similar to how theab3
feature set works. However, the feature description says it's "used when building Python extension modules" so it won't do anything for me.My use case
I'd like to build an app with Rust <-> Python, but Rust first instead of Python first. I actually need Python 3.7 support, but I'd also like for users to be able to choose a newer Python version if they want. I've figured out how to set different Python interpreters by setting PATH before the interpreter is initialized, but I'd like it to be able to optionally use any newer Python version even if that means that I need every Python interpreter I just want one single binary for app user convenience.
The text was updated successfully, but these errors were encountered: