07-26, 11:50–12:00 (US/Eastern), 32-141
The Julia ecosystem has super fast and performant packages, but not always upon first use. This may be alleviated using system images and this talk presents a convenient workflow to ship them. Additionally, it discusses various challenges when doing so and shares our experience in reliably tackling them.
Julia's packages usually compose well with each other. Hence it is common to see people using different packages together. It is often a design choice to split work across different packages.
Often, users add all the packages used in a tutorial or documentation to a local environment; end up with different versions, often leading to unintended results. Partly, a super-set Manifest.toml could solve it. However, a simple Pkg.up or similar operation could alter it. Did you say you pinned it? Instantiation and precompilation still lurk around. It is unreasonable to keep users waiting from using your highly performant, super-fast package.
With system images, one can start using packages quickly. However, you can't hand them over and expect them to work all the time. System images can sometimes fail to build; and often fail to relocate. Occasionally, they fail to start even on the same machine. We will walk through - how to interpret and fix these errors.
We need to deal with lots of releases of packages. One should ensure that the latest and greatest is delivered while maintaining consistency.
We want to talk about how to alleviate the issues in shipping with a mostly-contained and relocatable bundle that includes various components like a relocatable sysimage, additional packages for stdlib and a stackable depot with a pinned environment and more. These bundles should include all the artifacts necessary to run while not being bloated by them.
Distributing private registries and packages is tricky. We will discuss how to enable it without giving away the source code.
Our talk aims at decluttering the workflow of shipping packages by talking about how to set up one and the pitfalls; how to recognize and avoid them. It should give a better idea of how people can reliably build and share relocatable products to increase user adoption.
Joris is driven by a need for automation and to make things easier for himself, typically while first making them harder. He has been creating CI processes for Julia (and other languages) for as long as he has been programming in Julia (which has been a while), primarily for GitLab, but also for other platforms such as GitHub and Buildkite. He has also been building web-based Julia applications for the same amount of time, trying to find more efficient ways of building those at every step.
Joris is the technical team lead for the JuliaSim product and applications team.
