Hooks into startup

[jlapeyre]

pyjulia allows me to choose path to the julia executable like this

api = LibJulia.load(julia=julia_path)
api.init_julia()

I use this to provide several ways for the user to specify which Julia to use. A related question is whether juliacall supports development versions of Julia. It's not possible to try because the process of looking for a version of Julia (in the user's path, I suppose) and downloading a Julia is opaque with no hooks as far as I can tell.

Currently I

• Support three ways to specify which Julia executable to use: 1) supply the path in a file that is checked for existence. 2) look for ./julia/ in the top level in case the user put it there. 3) Look in the user's path
• Manage the Julia packages using the Julia-native Project.toml file
• Check for the existence of and download a registry from a single URL so all my packages that are not in the general registry can be found.
• Regarding the last two points. If something goes wrong with my automation, the user can install the registry and instantiate the Julia project manually, because my python layer is not essential.
• Manage compiling and loading a custom system image. (This is also in issue Support for using a custom system image? #71)

The other side of the coin, a big disadvantage of pyjulia compared to juliacall, is that I have to manage all of this myself in pyjulia, and for all platforms (but I only develop in linux). juliacall has a lot of machinery for locating julia executables and managing dependencies and does it for three platforms. This makes juliacall very attractive. So I'm wondering if there are some undocumented ways to achieve some of the items above. Even if there are not, I'd like to try juliacall because of the additional flexibility in controlling conversion.

One workaround is

• Instead of a registry, use the json file to manage Julia dependencies that is required by juliacall. I can put a URL for each package in this file.

[cjdoris]

The opaqueness is intentional, so that multiple packages all depending on JuliaCall can coexist. The only way a typical user should customise things is to specify dependencies in a juliacalldeps.json file. Dependencies from different packages are all merged and resolved together.

If the user really wants to specify the Julia executable to use, they can set the environment variable PYTHON_JULIACALL_EXE.

Something not currently supported is adding Julia packages from registries other than General. I could add an entry to juliacalldeps.json to support that. As you say, a workaround is to pass the URL of the package instead, but you don't get as good dependency resolution that way.

[jlapeyre]

The only way a typical user should customise things is to specify dependencies in a juliacalldeps.json file.

Why don't you have the user create a Julia-native Project.toml file? Doesn't this resolve dependencies efficiently as well? Is it because you want to present a more python-like interface to the package author? Or is there another reason? It looks like you wrap PackageSpec. Maybe this so you have more fine-grained control over the Julia project.

[cjdoris]

Yeah Project.toml doesn't specify enough information, for example you can't specify that a package lives in a particular repo or local path.