@MilesCranmer has put together a pull request to start directing folks to juliacall, the Python counter part of PythonCall.jl, from pyjulia.
As we start down this road, I would like to start planning for the deprecation of pyjulia.
A few questions:
I think itâs obvious we should do this. Iâm not sure there are many pyjulia users, but hard to know for sure, exept for users as part of publised packages.
I know of a few Julia packages wrapped for Python (or R) users, such as diffeqpy, and it already moved. Actually all of the few packages I know of.
This question is maybe better posted to some Python users/discourse.
I think we should may deprecate PyCall tooâŚ
And packages using it, e.g. PyCall. We already have its replacement PythonCall, and Iâm thinking could PyPlot depend on both, i.e. if PythonCall is already loaded (as might very well be done, for other packages or your own code) then PyPlot will still work, just be a wrapper for PythonCall.
There are rather many packages depending on PyCall, some might not be too important (and you can use PyCall and PythonCall together, itâs just a hassle for users to configure correctly), e.g. Pandas.jl, is likely not too much used. Deprecate or migrate some of them, at least much-used packages?
We already have PythonPlot.jl.
I know, I have in mind users that might follow some tutorials, and so using PyPlot (not using Plots), and have problem when using PythonPlot, even indirectly, not knowing why.
julia> using PythonCall
julia> using PyCall
free(): invalid pointer
[1242766] signal (6.-6): Aborted
Itâs not the best experience, for newbies, or those not reading the docs, and worse if this is indirect, you could be using some arbitrary package A. and B. the do the above for you.
If you reverse the order, or even do it on the same line, but only with this order:
julia> using PyCall, PythonCall
ERROR: InitError: Python: SystemError: initialization of _datetime did not return an extension module
[That actually Aborts too in 1.9.4, not sure why only there, and if we can rely on it not happening in 1.10+.]
which is also non-ideal, but that exception could be caught and made more user-friendly, pointing to a solution, even better would be avoiding needing to change anything, and thatâs at least possible for PyPlot.
And it doesnât work for me, went back to PyPlotâŚ
And then we have GitHub - JuliaControl/SymbolicControlSystems.jl: C-code generation and an interface between ControlSystems.jl and SymPy.jl which depends on PyCall⌠I tried to make it work with PythonCall and failed to do soâŚ
May I ask what the issue was? (I have been playing with the idea of migrating to PythonPlot. so I am curious to know.)
I think the discussion here should be stay focused on pyjulia, rather than PyCall.jl.
PyCall.jl is at least maintained (and is completely separate) so is viable for the forseeable future. pyjulia is not maintained, however, so users deserve to know this.
Currently, users are only told about the existence of juliacall in GitHub issues and discourse posts, so I think we should simply present them that information earlier. (Rather than after they learn how to use an unmaintained package and encounter some issue with it.)
The issue is that pyjulia actually has more GitHub stars, a better placement in Google search, and a not-too-inactive commit history (from me and @mkitti keeping the lights on), so a new user would actually be directed to it first before juliacall.
Not to mention the PythonCall.jl repo has that â.jlâ in its name and mostly Julia files:
so it would seem completely reasonable that a new user wanting a way to call Julia from Python would try out pyjulia first. Itâs not fair to them that they waste time learning a package the maintainers have moved on from (and appears to segfault frequently on Python 3.12). A message in the README is the least we can do.
Still unresolvedâŚ
tkagg works, but it is ugly. I donât have this issue with PyPlot.
I set ENV["MPLBACKEND"] = "tkagg" in my startup.jl and then got my plots.
I am not a user of either of them but this seems like a natural solution, if you really just want to kill pyjulia in favor of juliacall but donât want to disrupt user experience.
Given the pace of development being as slow as it is, I think it is fair to assume nobody is going to take the time to implement such a wrapping (there are many many things that need to be wrapped for it to be compatible; I think itâs a lot of work). I think the priority, which we can implement today, is to simply point users to juliacall on the README.
The pull request in the original post has been merged. Unless a new maintainer is interested in continuing pyjulia, I will focus my efforts in this area on smoothing the transition from pyjulia to (py)juliacall.
