Module startup 

What yapi loads from chest manifests: the installed extensions, with the grants, event policy and module root each runs with, and the placed skills.

Structs

FilePolicies

The policies of extension files, so a policy applies whichever source of the same file loads it.

Installed

What the installed entries of chest manifests give yapi.

Loaded

What chest gives one run of yapi, with the problems to show by manifest path: warnings and notices of the startup sync, entries left out, and manifests that fail to load.

Policy

What an extension runs with: its grants, its pi.events policy, and the folder it loads modules from without file access. It has no default, so every file says which one it gets.

Functions

file_policies

The policy of each extension file the resolver gave a chest: source in resolved, loaded or shadowed, from its package’s entry in installed, with the entries installed left out. A file that several entries give gets what all of them allow. A chest file whose package has no entry runs with no grant and the isolated event policy, and adds a line to problems under its source.

installed

What chest gives a run in project_root, as load would, without installing anything: for yapi config, which shows what a run loads.

installed_inputs

The extensions and skills project has installed, locked and up to date, or patched, for a run in project_root: a stale or unlocked entry gives nothing until chest install. Entries left out for a reason the user should see add a line to problems.

load

What chest gives a run of yapi in project_root: the project manifest, only when trusted, and the user’s global one, each when it installs anything. Each puts back what its lock pins and is missing, unless offline, and skips stale or unlocked entries with a warning. It never writes a lock or .gitignore.

needs_trust

Whether the project manifest of project_root installs anything, so it needs the project’s trust as other project files that run code do. One with only [package], which describes the project as a package, does not. A manifest that does not parse needs trust too.

project_manifest

The project manifest of project_root: the file MANIFEST_ENV names relative to it, else chest.toml. None when the variable names a file outside the project, as chest refuses it too. Its lock is the file beside it named with .lock.

Type Aliases

Policies

The policies of chest’s packages, by the scope and source the resolver gives their files, such as ("project", "chest:todo"). installed_inputs builds the packages and their policies in one place, so they always match.