Julep: PEP 723 block goes between @pure and def, not at module top

Julep: PEP 723 block goes between @pure and def, not at module top

TL;DR

register_pure and bundle publishing capture pure source with inspect.getsource(fn), which returns text from the decorator line through the function body only. It does not include a module-top block. So a module-top # /// script block is silently dropped from the captured source: the pure publishes as no-dependency, deploy passes (the import works on the native host), then the wasm-tier run fails at import.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

Place the block between @pure(...) and def. The supported WASI-wheel set is exactly pydantic-core and regex; if every declared dependency is in that set, the pure resolves to the wasm tier with a pre-initialized wasm environment component and an envHash. An off-list dependency such as numpy has no curated WASI wheel and can run only on the native tier, a uv-managed subprocess in a worker venv. Native tier is opt-in per pure: the pure name must be present in the JULEPPURENATIVE_DEPS allowlist at both publish/deploy and worker resolution. Without that grant, publish fails closed and names the pure plus the offending dependency, and a worker refuses to register an off-list native-tier pure it has not granted.

Context: Official docs (Julep authoring guide, Third-Party Dependencies on Pures): a pure declares third-party deps with a PEP 723 inline-script-metadata block, and the placement of that block is load-bearing. Put it in the wrong place and everything looks fine until the wasm-tier run fails at import.

Source: Official docs (Julep authoring guide, Third-Party Dependencies on Pures): a pure declares third-party deps with a PEP 723 inline-script-metadata block, and the placement of that block is load-bearing. Put it in the wrong place and everything looks fine until the wasm-tier run fails at import.

Verified resolution: registerpure and bundle publishing capture pure source with inspect.getsource(fn), which returns text from the decorator line through the function body only. It does not include a module-top block. So a module-top # /// script block is silently dropped from the captured source: the pure publishes as no-dependency, deploy passes (the import works on the native host), then the wasm-tier run fails at import. Place the block between @pure(...) and def. The supported WASI-wheel set is exactly pydantic-core and regex; if every declared dependency is in that set, the pure resolves to the wasm tier with a pre-initialized wasm environment component and an envHash. An off-list dependency such as numpy has no curated WASI wheel and can run only on the native tier, a uv-managed subprocess in a worker venv. Native tier is opt-in per pure: the pure name must be present in the JULEPPURENATIVEDEPS allowlist at both publish/deploy and worker resolution. Without that grant, publish fails closed and names the pure plus the offending dependency, and a worker refuses to register an off-list native-tier pure it has not granted.

Source URL: https://github.com/julep-ai/julep/blob/HEAD/docs-site/content/docs/guides/authoring-flows.md#third-party-dependencies-on-pures-pep-723