Registered extension project_path is manifest-less for registry installs, so the extension can't boot #62

Closed
opened 2026-07-15 09:52:19 -07:00 by mthelm85 · 1 comment
mthelm85 commented 2026-07-15 09:52:19 -07:00 (Migrated from github.com)

register_extension() defaults project_path to pkgdir(KaimonSlate). For a registry install (pkg> app add KaimonSlate) that's the depot package dir (~/.julia/packages/KaimonSlate/<slug>): it contains Project.toml and kaimon.toml, but no Manifest.toml, and Pkg write-protects it.

Kaimon spawns the extension with --project=<project_path>, and the boot script's Pkg.resolve() tries to repair the environment — but it can't write a manifest into the protected depot dir (SystemError: opening file ".../Project.toml": Permission denied when attempted manually), so using KaimonSlate fails to resolve the package's deps and the extension crash-loops.

This works for dev checkouts (instantiated project in place), but not for the documented app add install path.

Workaround that got me running: copy pkgdir(KaimonSlate) to a writable directory, Pkg.add("Kaimon") + Pkg.instantiate() there, and register_extension(force=true, project_path=<copy>).

Possible directions: have Kaimon materialize a managed, instantiated environment per extension (e.g. under its cache dir) with the extension package added to it, keeping kaimon.toml discovery at the package dir; or have register_extension() build such an env at registration time. Happy to contribute a PR once there's a preferred design.

Related: #61 fixes the same manifest problem for the Kaimon entry on the extension's load path.

`register_extension()` defaults `project_path` to `pkgdir(KaimonSlate)`. For a registry install (`pkg> app add KaimonSlate`) that's the depot package dir (`~/.julia/packages/KaimonSlate/<slug>`): it contains `Project.toml` and `kaimon.toml`, but no `Manifest.toml`, and Pkg write-protects it. Kaimon spawns the extension with `--project=<project_path>`, and the boot script's `Pkg.resolve()` tries to repair the environment — but it can't write a manifest into the protected depot dir (`SystemError: opening file ".../Project.toml": Permission denied` when attempted manually), so `using KaimonSlate` fails to resolve the package's deps and the extension crash-loops. This works for dev checkouts (instantiated project in place), but not for the documented `app add` install path. Workaround that got me running: copy `pkgdir(KaimonSlate)` to a writable directory, `Pkg.add("Kaimon")` + `Pkg.instantiate()` there, and `register_extension(force=true, project_path=<copy>)`. Possible directions: have Kaimon materialize a managed, instantiated environment per extension (e.g. under its cache dir) with the extension package added to it, keeping `kaimon.toml` discovery at the package dir; or have `register_extension()` build such an env at registration time. Happy to contribute a PR once there's a preferred design. Related: [#61](https://github.com/kahliburke/Kaimon.jl/pull/61) fixes the same manifest problem for the *Kaimon* entry on the extension's load path.
kahliburke commented 2026-07-17 17:39:23 -07:00 (Migrated from github.com)

Fixed by #65 (merged to main, shipping in v2.0.8).

Kaimon now does exactly the managed-environment approach you proposed: on spawn, a registry/app-installed extension (manifest-less project_path) gets a Kaimon-managed, instantiated environment at ~/.julia/environments/kaimon-ext/<namespace> — Kaimon Pkg.develops the package from its source dir and installs its deps there, then launches --project against it, while kaimon.toml discovery stays at the package dir. Built once, cached, rebuilt when the source changes. Dev checkouts with their own manifest are launched as-is, unchanged.

Combined with #61 (which puts Kaimon's active env on the extension load path so using Kaimon resolves), a clean app add Kaimon + app add <extension> now boots the extension end-to-end. Verified live with app add KaimonSlate.

Thanks for the sharp diagnosis and the design suggestion — it's essentially what shipped.

Fixed by #65 (merged to `main`, shipping in v2.0.8). Kaimon now does exactly the managed-environment approach you proposed: on spawn, a registry/app-installed extension (manifest-less `project_path`) gets a Kaimon-managed, instantiated environment at `~/.julia/environments/kaimon-ext/<namespace>` — Kaimon `Pkg.develop`s the package from its source dir and installs its deps there, then launches `--project` against it, while `kaimon.toml` discovery stays at the package dir. Built once, cached, rebuilt when the source changes. Dev checkouts with their own manifest are launched as-is, unchanged. Combined with #61 (which puts Kaimon's active env on the extension load path so `using Kaimon` resolves), a clean `app add Kaimon` + `app add <extension>` now boots the extension end-to-end. Verified live with `app add KaimonSlate`. Thanks for the sharp diagnosis and the design suggestion — it's essentially what shipped.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
kahliburke/Kaimon.jl#62
No description provided.