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

Using julia shared libraries as python C exstensions #25

Closed
SimonDanisch opened this issue Feb 19, 2018 · 5 comments
Closed

Using julia shared libraries as python C exstensions #25

SimonDanisch opened this issue Feb 19, 2018 · 5 comments

Comments

@SimonDanisch
Copy link
Collaborator

I will try to post details of my progress here, in the hope to have a few more eyes looking at the problems I encounter.
Here is a start: https://discourse.julialang.org/t/calling-julia-shared-library-from-python-linking-libraries/9169

Let's hope we can do this quickly, this feature would be so awesome! :)

@SimonDanisch
Copy link
Collaborator Author

PR: #26

@tkf
Copy link
Member

tkf commented Oct 31, 2018

Hello PackageCompiler.jl devs, thanks for the awesome work! I find this issue interesting so allow me to join in. I'm a member of PyJulia so I may be biased 😉 (but try not to).

I think the biggest pros of loading library generated by PackageCompiler.jl is that it can release Python's Global Interpreter Lock (GIL). It means that you can run Python code and Julia code in parallel. However, the flip side of this is that you can't use PyCall (at the moment) for passing complex objects in between Julia and Python. But there are lot you can do with simple C types. (I guess something like Apache Arrow would help it too.) Another consequence is that it will not have the problem with precompilation cache for using PyCall.jl JuliaLang/julia#28518. On the other hand, PyJulia uses PyCall so it inherits all of PyCall's merits and restrictions.

Extending this line of thinking, I think the usage of the library generated by PackageCompiler.jl may be better focusing on C type-based interface rather than strongly coupling to Python C-API since using PyCall would be the easiest choice for this purpose. It means to not link against libpython (i.e., don't make it a "Python C extension" in a narrow sense) and use ctypes or cffi. Armin Ronacher discussed it in various talks like: https://www.youtube.com/watch?v=yhiHmBE9fNU (and https://www.youtube.com/watch?v=zmtHaZG7pPc&t=1095; I couldn't find a good readable material but this is close: https://blog.sentry.io/2017/11/14/evolving-our-rust-with-milksnake). The main point is that the distribution is going to be much easier since you don't need to build against various versions of libpython. For a working ctypes example, see the first link in #144. It would be nice to have an example of distributable Python pacakge combining PackageCompiler.jl and (maybe) milksnake (though I've never used it). It would allow Python users to just pip install some package without knowing Julia is working in the background.

@kdheepak
Copy link
Collaborator

kdheepak commented Aug 2, 2019

We have a working example of this in PR #261.

KristofferC added a commit that referenced this issue Feb 9, 2020
* wip only using needed stdlibs

* only include needed stdlibs in apps

* make default off
@ViralBShah
Copy link
Member

ViralBShah commented Apr 24, 2020

Would be nice to see if some of the PRs here can be revived (perhaps restarted?) and made to work.

@KristofferC
Copy link
Member

This feels kind of stale. If this is still of interest, please open a new issue with updated information.

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

5 participants