FYI: Support PythonCall.jl

[PallHaraldsson]

https://cjdoris.github.io/PythonCall.jl/stable/juliacall/#Installation

I checked it myself and it does download Julia for you, as claimed (1.7) and its example works. So I tried with your package to see if it worked too, but got some PyCall error, understandably. I just think if might help your users to not have to download or know much about Julia. I've not used PythonCall extensively myself. It does have a larger startup cost (currently, I have a PR coming up bringing down to 3.06 sec. maybe further).

julia> @time using PythonCall
  4.431433 seconds (2.88 M allocations: 164.448 MiB, 1.13% gc time, 82.64% compilation time)

julia> @time using PyCall
  0.978491 seconds (963.43 k allocations: 62.176 MiB, 1.16% gc time, 73.61% compilation time)

compared to:

$ ~/julia-1.7.0/bin/julia -O0 --compile=min

julia> @time using PythonCall
  1.051802 seconds (816.71 k allocations: 58.820 MiB, 1.40% gc time, 17.52% compilation time)

julia> @time using PyCall
  0.630133 seconds (484.69 k allocations: 35.356 MiB, 52.99% compilation time)

PyCall didn't work right away, I had to build it.

[sibyjackgrove]

@PallHaraldsson Have you compared JuliaCall with PyJulia? Diffeqpy uses PyJulia for calling Julia from Python.

[PallHaraldsson]

I haven't used PythonCall much but it compares to PyJulia. I realize PyJulia is currently used, I'm not sure PythonCall could be a non-default option, might be confusing to have two options. It might be better to support PythonCall only.

[ChrisRackauckas]

Having two options is untenable. Really it needs to be one well-supported one. If it's just the Julia installation, right now it seems like pyjulia with JuliaPy/pyjulia#473 might be best. I would be happy if @00sapo could help us figure out a nice solution for automating the diffeqpy installation.

[PallHaraldsson]

PythonCall already downloads Julia for you, that was my main reason for proposing the change, otherwise your call.

[ChrisRackauckas]

That's a gigantic change. If you're willing to do all of that work then go for it.

[00sapo]

Hello, I did some comparisons that you can use for your use case to check if juliacall is as performant as pyjulia: https://github.com/00sapo/pyjulia-vs-juliacall. If you do that, feel free to send a PR.

In that project there are also usable examples of how mu proposal JuliaPy/pyjulia#473 can be used, and it's compared with juliacall approach.

Juliacall downloads Julia at the first usage, I don't actually like this way of working. My function can be used on the user need. Morever , on my system (Linux Manjaro), my function can reliably detect the existing Julia version, JuliaCall can't do that.

Maybe, we could create a separate python package that simply provides this function and other tools if needed (e.g. a pre-compiled environment to improve startup time).

[jlapeyre]

There are very big differences between PythonCall and PyJulia. The fact that one downloads julia automatically is a minor detail in comparison. It shouldn't determine the choice--- like buying car because you like the cup holder. For example, the script that Chris linked to or something like it would be reasonable for automatic downloading.

• pythoncall does not yet support loading custom system images (there is discussion in the issues)

• pyjulia is much more flexible in adding hooks for configuring and loading, eg specifying the path to the executable, the system image, etc. pythoncall by design has the process more locked up.

• pythoncall manages a Julia project by specifying a JSON format (that sort of parallels Project.toml). It includes a mini package manager that makes sort of low-level calls to Pkg. In fact it has a few other systems like this. They look well written, but that's quite a bit to maintain.

• A rather big difference: The semantics of and facilities for translating objects, copying, sharing, etc. are quite different.

[ChrisRackauckas]

Now done via PythonCall