A custom sysimage seems to be the current (best?, only?) solution to the latency issue. Below I only talk about Sysimages, not about Apps or libraries. Contrary to the
Apps case, I’m only concerned about weaker form of “relocability”. I envision a given sysimage being (re)-used only in very similar environment: same OS, same version of Julia, same hardware (even if not same host), same depot, same artifacts, access to the same registries etc.
I see two different use cases:
apporiented image (AOI): the build environment (as defined by
Pkg, that is
Manifest) is fixed. The image will only be used with this environment. It contains an “application” package that is driven by a script. Usage is
julia -Jmyapp.so myscript args....
devoriented image (DOI): it will be used as a replacement of the default sysimage for a large range of use cases. REPL session, kernel for Juno or Jupyter, running test quickly in CI…
Sysimage have the well known problem that they break the semantics of the environment of the current active project.
However, in the first case (AOI) this is not an issue by definition. All packages in the image behave essentially like an extended standard library. From the viewpoint of the user of the image, an update of the image is like an update of the Julia distribution itself. This can be handled by the local maintainer of the image.
Question: is there some good tooling to help the maintainer of a set of AOI images?
- If yes, I’ve not seen it mentioned so it does not seem very popular, why?
- If no, why? is it “only” a question of manpower/priorities (of course completely understandable for a project like julia)? Or is this fundamentally misguided?
Note 1: I’m aware of the (for now) limited custom image feature of the VsCode extension. Also of at least one package to help create custom kernel for IJulia, and some discussions here…
Note 2: I haven’t got the impression that this is “pushed” very much to the users. Maybe because of the lack of tooling? Maybe because it requires using PackageCompiler and have a “somewhat good” grasp of the Julia runtime (at least to be clear about the difference and pitfalls between the AOI and DOI use cases)
I’ve also thought a bit about the second case. I believe DOI image could be made to work well in practice by separating the set of packages they contain into two different parts:
- The public interface: these packages are the ones meant to be used by the client of the image. The image should be used only in environments where the public packages are pinned to exactly their version in the image. Thus, the public packages must be part of the Project (and not only Manifest) of the client environment.
- The internal interface: all the non-public packages. These will mostly be the transitive dependencies of the packages for which of the image was built (i.e. the arguments given to
create_sysimage). We do not want all packages in the image to be part of the Project of the client, and we certainly do not want them to be pinned! (this would reduce the DOI case to nearly the AOI one). The solution here is to use side-loading (which is common for runtime using so/dll). I think it could be implemented by a “clever” use of the Pkg+PackageCompiler. Of course the cost would be code duplication each time an internal package is added to the environment of the client (since the runtime would see it as a different package, i.e. different uuid).
Question Does the above idea “kind of make sense”? As it already been discussed ad-nauseam and found lacking? How? Why?
This post is already way too long… If the idea of a sysimage builder that make the DOI use case workable is not too silly I could describe how I think one could do points 1&2 above.
(I’m quite motivated, I’ve users in a enterprise scenario that would require the full DOI case with guarantee that the runtime honor their Project+Manifest specs, as it does without a custom image. Also subject to another post if anyone is interested)