Is PyJulia being maintained?

[Benny]

@ChrisRackauckas

But what we’ve seen with the Julia language bridges is that, over time those maintainers end up with essentially 100% of their projects in Julia and so many of them tend to become core maintainers of the Julia language itself (since they already know some system programming stuff from building language bridges, it’s a natural transition)

The jig is up.

@juliohm

People find it easier to start a whole new package in a whole new repo because it is harder to work in branches and merge into a main branch for a breaking release?

I’m not sure if it was entirely accurate for the PythonCall developer to say that JuliaCall is just “one [Python] file” (pysrc/juliacall) that has to “find Julia and get it to import PythonCall”; the Julia code (src/jlwrap) that wraps Julia types for Python does execute strings of Python code interpolated with computed Julia literals. But that just goes to show that it’s a vastly different approach to PyJulia, which is basically a Python package.

I’ll draw your attention to this comment by one of the developers of PyCall; I have not seen a similar comment from a PyJulia developer. TLDR: PyCall and PyJulia were created in Julia’s volatile package-lacking v0 phase, and a reasonable design overhaul for the different needs of today would be such a disruptive major revision, it warrants a different package.