Summary
perry-ffi is the stable FFI surface that any native bindings package (per perry.nativeLibrary in package.json) compiles against. It's part of the Perry monorepo at crates/perry-ffi/ but isn't published to crates.io.
This means every npm package that ships a native/*/ Rust crate using perry-ffi has to write perry-ffi = { path = "../../../../perry/perry/crates/perry-ffi" } — a relative path that only resolves in a sibling-checkout layout (~/code/hone/, ~/code/perry/, etc.).
After npm install, the relative path lands inside node_modules/... and can't reach a sibling Perry checkout. Cargo bombs with "no matching package found for perry-ffi".
Concretely hit while using @honeide/editor's native crates from a Perry app — the npm-published native/macos/Cargo.toml has perry-ffi = { path = "../../../../perry/perry/crates/perry-ffi" }, which is unresolvable after install. Workaround was to patch the path to an absolute one pointing at a Perry checkout, but that's per-developer-machine and doesn't survive CI / reinstall.
What I'd like
Publish perry-ffi to crates.io so wrappers can write perry-ffi = "0.5" and cargo build resolves it without any local Perry checkout. Each Perry release would publish a matching perry-ffi version, consistent with the PERRY_FFI_ABI_VERSION = env!("CARGO_PKG_VERSION") lockstep that crates/perry/src/commands/compile/resolve.rs already documents.
The [features] runtime-link = ["dep:perry-runtime"] flag can stay default-off — only Perry's own tests need it, and external wrappers don't.
Alternative if direct publication isn't possible
A documented [patch.crates-io] snippet wrappers can include verbatim, plus a way to ask perry itself where its perry-ffi lives (e.g. perry --print perry-ffi-path). Then a small build.rs in each wrapper can write the patch automatically. More fragile than publishing, but at least mechanical.
Why this matters
It's a hard gate on shipping any native bindings package via npm — the perry.nativeLibrary manifest exists specifically so npm packages can describe their native surface, but the cargo dependency graph that needs to type-check against perry-ffi can't be expressed portably today. @honeide/editor works around it with a sibling-checkout requirement; we'd much rather not.
Summary
perry-ffiis the stable FFI surface that any native bindings package (perperry.nativeLibraryin package.json) compiles against. It's part of the Perry monorepo atcrates/perry-ffi/but isn't published to crates.io.This means every npm package that ships a
native/*/Rust crate using perry-ffi has to writeperry-ffi = { path = "../../../../perry/perry/crates/perry-ffi" }— a relative path that only resolves in a sibling-checkout layout (~/code/hone/,~/code/perry/, etc.).After
npm install, the relative path lands insidenode_modules/...and can't reach a sibling Perry checkout. Cargo bombs with "no matching package found forperry-ffi".Concretely hit while using
@honeide/editor's native crates from a Perry app — the npm-publishednative/macos/Cargo.tomlhasperry-ffi = { path = "../../../../perry/perry/crates/perry-ffi" }, which is unresolvable after install. Workaround was to patch the path to an absolute one pointing at a Perry checkout, but that's per-developer-machine and doesn't survive CI / reinstall.What I'd like
Publish
perry-ffito crates.io so wrappers can writeperry-ffi = "0.5"andcargo buildresolves it without any local Perry checkout. Each Perry release would publish a matchingperry-ffiversion, consistent with thePERRY_FFI_ABI_VERSION = env!("CARGO_PKG_VERSION")lockstep thatcrates/perry/src/commands/compile/resolve.rsalready documents.The
[features] runtime-link = ["dep:perry-runtime"]flag can stay default-off — only Perry's own tests need it, and external wrappers don't.Alternative if direct publication isn't possible
A documented
[patch.crates-io]snippet wrappers can include verbatim, plus a way to askperryitself where itsperry-ffilives (e.g.perry --print perry-ffi-path). Then a small build.rs in each wrapper can write the patch automatically. More fragile than publishing, but at least mechanical.Why this matters
It's a hard gate on shipping any native bindings package via npm — the
perry.nativeLibrarymanifest exists specifically so npm packages can describe their native surface, but the cargo dependency graph that needs to type-check againstperry-ffican't be expressed portably today.@honeide/editorworks around it with a sibling-checkout requirement; we'd much rather not.