What’s the proper way to create a custom sysimage for the following situation:
I am developing a package with at least a moderately large set of dependencies (Trixi.jl) and I would like to speed up startup latency by compiling all dependencies into a sysimage with PackageCompiler.jl. How do I properly invoke PC.jl such that all dependencies are included but not my package itself (since I am actively developing it)?
Right now, I am doing something like the following, where I copy the Project.toml from my package to another folder, remove the everything but the [deps] and [compat] sections, instantiate it, then install my package in the same environment, and finallly run PC.jl with a script that exercises some functions of my package that in turn make use of the dependencies.
This seems like overly convoluted, thus I am sure that there must be an easier way to do it, right? During development, I usually run julia --project in my cloned package directory, and ideally I could just do that with a “special” PC.jl invocation to create a suitable sysimage.
Thanks for the reply! Yes, I am aware of this argument, and this is what I currently use as well. However, I am wondering if there really is no other solution than to extract the package names manually from the Project.toml. I am looking for something (logically, not literally) like create_sysimages(depsof(Trixi), ...) where depsof will return all dependencies of a given package, or alternatively where I can include all packages in the current project except a certain package.
In a related project, we’ve used the following to automatically extract and filter the dependencies from an existing environment:
# Get all packages from the current project
all_packages = String
for (uuid, dep) in Pkg.dependencies()
dep.is_direct_dep || continue
dep.version === nothing && continue
# Remove unneeded packages
do_not_include = ["PackageCompiler","SIEGE"]
package_list = filter(x -> x ∉ do_not_include, all_packages)
This method would just use whichever version is in the current environment. I don’t think it’s possible to have both. For instance, when I try the following, adding the local version just replaces the public version, and vice versa.
pkg> activate --temp
pkg> add MyPackage # public version
pkg> dev /path/to/local/MyPackage