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`' For more details and options, see README. 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 :slight_smile: 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: ❯ julia -e 'using RunBinary; @run SQLite `-version`' 3.47.2 2024-12-07 20:39:59 2aabe05e2e8cae4847a802ee2daddc1d7413d8fc560254d93ee3e72c14685b6c (64-bit) Pass verbose=true for the old (very verbose) behavior in case you need it for debugging: ❯ julia -e 'using RunBinary; @run SQLite `-version` verbose=true' Activating new project at `/var/folders/2j/9vtd991d201dbkh9dnx3wvy00000gq/T/jl_v6ZX81` Resolving package versions... Updating `/private/var/folders/2j/9vtd991d201dbkh9dnx3wvy00000gq/T/jl_v6ZX81/Project.toml` [76ed43ae] + SQLite_jll v3.47.2+2 Updating `/private/var/folders/2j/9vtd991d201dbkh9dnx3wvy00000gq/T/jl_v6ZX81/Manifest.toml` [692b3bcd] + JLLWrappers v1.7.0 [21216c6a] + Preferences v1.4.3 [76ed43ae] + SQLite_jll v3.47.2+2 [56f22d72] + Artifacts v1.11.0 [ade2ca70] + Dates v1.11.0 [8f399da3] + Libdl v1.11.0 [de0858da] + Printf v1.11.0 [fa267f1f] + TOML v1.0.3 [4ec0a83e] + Unicode v1.11.0 [83775a58] + Zlib_jll v1.2.13+1 3.47.2 2024-12-07 20:39:59 2aabe05e2e8cae4847a802ee2daddc1d7413d8fc560254d93ee3e72c14685b6c (64-bit) Activating project at `~/.julia/environments/v1.11` 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.

RunBinary.jl is now a Julia App The most recent Julia version (1.12) supports so-called “apps”, and now RunBinary.jl can utilize this! Run: import Pkg; Pkg.Apps.add("RunBinary") in Julia 1.12 to install the app, which then should become available from your terminal as: runbinary ImageMagick.convert input.png output.jpg runbinary SQLCipher database.db runbinary difmap ... for any binary available as a jll (mostly, from the Yggdrasil repo). One time setup – to easily run any available binary in an ad-hoc way :star_struck: Please report if anything doesn’t work, I’m new to the “julia apps” setup.

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?

[image] mchitre: not globally 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.

[ANN] RunBinary.jl: easily run binaries from YggDrasil

Package Announcements

oschulz June 19, 2021, 11:44am 2

There’s also ygg (see also Announcing ygg), maybe there’s some synergy potential here?

Topic		Replies	Views
Announcing ygg Package Announcements	11	3141	February 21, 2021
Do not assume BB binary is used everywhere Internals & Design	47	4363	February 16, 2021
BinaryBuilder or running `build.jl` as root? General Usage question , binarybuilder	17	1073	June 26, 2023
How to handle C dependency in packages New to Julia package	17	2262	January 29, 2020
Moving away from "manual JLL packages" in the General registry Internals & Design	40	2666	October 21, 2026

[ANN] RunBinary.jl: easily run binaries from YggDrasil

Related topics