-
Notifications
You must be signed in to change notification settings - Fork 7
Description
Statics let packages use some "magic functions" to pull in artifacts from the outside world without needing to handle cryptographic hashes by hand. During project analysis, Brioche looks at the script AST to determine the arguments used for each static, supporting either literal values, or template literals (with restrictions). This makes it impossible to build higher-level helpers that use statics under the hood.
One motivation is how we handle crates.io downloads today. Here's a modified snippet from our typst package:
const source = Brioche.download(
`https://crates.io/api/v1/crates/typst/${project.version}/download`,
)
.unarchive("tar", "gzip")
.peel();Ideally, we'd expose a helper to hide the specifics of crates.io URL structure (that way, if there's ever e.g. a /v2/ API, we could upgrade without needing to touch every package that pulls from crates.io):
// packages/rust/project.bri
export function downloadCrate(crateName: string, version: string): std.Recipe<std.Directory> {
return Brioche.download(
`https://crates.io/api/v1/crates/${crateName}/${version}/download`,
)
.unarchive("tar", "gzip")
.peel();
}
// packages/typst/project.bri
import { downloadCrate } from "rust";
const source = downloadCrate("typst", project.version);...but this snippet fails today. Brioche.download will try to lock the download function within the rust package but can't determine what the URL will be, and the typst package isn't calling any static functions and so will fail.
In a perfect world, it'd be ideal if we could use the above snippet exactly as-is... but realistically we'll probably need to make some compromises to implement this.