Thanks to BinaryBuilder, some programs are now much easier to install as Julia *_jll packages compared to other solutions. However, simple no-setup ways to run these programs were not available yet to my knowledge.
This is where RunBinary.jl (registered) comes to help. Its API consists of a single macro @run that installs the required jll package in a temporary environment and executes the specified binary:
@run SQLCipher.sqlcipher
A common usecase is to run via CLI:
$ julia -e 'using RunBinary; @run ImageMagick.identify `/path/to/file.jpg`'
The overhead is just about 2 seconds on my laptop:
$ time julia -e 'using RunBinary; @run HelloWorldC'
...
Hello, World!
2.20s user 0.86s system 144% cpu 2.116 total
This includes starting julia, creating a new temporary env, instantiating it, and running the target program. It further improves fourfold to 0.5 seconds with --compile=min.
Indeed, @ericphanson pointed me to ygg in slack when I asked about it.
As I understand, ygg’s approach is aimed at a somewhat different case of using jll binaries: set up all required programs beforehand, add paths to $PATH, etc. RunBinary is the alternative for running these programs in a more ad-hoc way with no additional setup needed (only julia + ]add RunBinary), and everything is garbage-collected by Pkg when not in use.
But I agree, in principle there may be some overlap…
RunBinary.jl happened to be one of those rare packages that don’t need any maintenance for years It’s one of my first Julia packages and has been working reliably since creation. It also remains compatible with all Julia versions since 1.6.
Julia + BinaryBuilder still is one of the easiest ways to install various software (assuming you have Julia installed already). And RunBinary.jl is a simple frontend to make ad-hoc install & run workflows maximally convenient.
There’s just one real update since 2021, in version 0.1.1 that should be registered momentarily:
Recently, I learned that one can silence Pkg operations by passing io=devnull. This allowed me to make RunBinary.jl usage even cleaner, now there’s no extra output at all – only what the underlying binary prints:
The only other thing I wish RunBinary.jl had is an easier way to run it. Something like julia -m RunBinary SQLite file.db?.. This may become possible in the next Julia version.
Neat! Is there a way to run a binary from a JLL package installed in some environment (not globally)? Like: runbinary --project=@img ImageMagick.convert input.png output.jpg?
runbinary doesn’t use and doesn’t affect the global Julia environment. Everything is installed into a temporary env – the idea is to have everything automatic, no manual setup nor cleanup.
So I suppose that ends up being a key difference with ygg — that’s a more traditional package manager with installation and version management, whereas this is a “just give me the latest version on the fly” sort of thing.
In practice, do you find it ends up GC’ing and re-downloading the JLLs often?
Yes, runbinary definitely aims to make running “anything” as simple as possible, no per-binary installation. Conceptually close to comma in Nix ecosystem.
I didn’t systematically measure how often GC/redownloads trigger, but it just reuses the existing Pkg cache policies.
It’s one of my first Julia packages and has been working reliably since creation. It also remains compatible with all Julia versions since 1.6.