magus v0.4.3 is out. See what's new
¶ View markdown source · ✎ Suggest an edit
2 min read

MGS1023: workspace provider reported an unusable project path

A spell wired with magus\workspace.provider(...) returned a project whose path magus cannot turn into a project. The message names the provider, the path it reported, and which rule the path broke:

[MGS1023] workspace provider "nx" reported project path "/abs/libs/foo":
project paths are relative to the workspace root, never absolute

The rules a reported path must satisfy:

Rule Why
non-empty a project is addressed by its path; there is nothing to address
relative, not absolute every project path in magus is repo-relative, so target identity is portable across machines
inside the workspace root magus never operates outside the workspace it discovered
not . the root project belongs to the magusfile that wired the provider
an existing directory a project's directory is what the cache key hashes and what its targets run in

Why this fails the load

A provider is code that shelled out to another tool, which makes its answer the least trustworthy input in the load path. magus rejects it rather than repairing it, and fails rather than skipping the entry: a dropped project is a target that no longer exists, and magus run test would report success having run nothing.

Resolution

Fix the provider's list_projects so every Project it returns carries a workspace-relative path to a real directory. Reporting the foreign tool's project root verbatim is usually right; nx show project <p> --json gives root in exactly this form:

export fun list_projects(target: Target, cb: fun(any)) > [Project] {
    // root comes from the tool already repo-relative: "libs/foo", not "/abs/libs/foo"
    return [Project{ path = "libs/foo", spells = ["nx"] }];
}

If the tool reports absolute paths, make them relative to the workspace root before returning them. The root is handed to the contract through cb:

final io = {<str: any>};
cb(io);
final root = io["root"] ?? "";

See also

MGS1023magusfileworkspace-providersprojectsspells
Last updated (895d94e4)
Earlier changes on this page (3)

Full history ↗ · Blame source ↗

Glossary

Workspace

The magus root directory that owns a set of projects and shared config; the unit magus operates over. Workspace in full.

Project

A directory magus recognizes as a unit of work (it has a magusfile); the unit of caching, scheduling, and dependency tracking. Project in full.

Magusfile

The magusfile.buzz that declares a project's targets (as export funs) and binds its spells. Magusfile in full.

Target

A named operation (build, test, ...) you invoke with magus run <target>; it may compose a spell's tool-native operations and depend on other targets. Target in full.

Op

A single tool-native command a target composes (long form: operation); the middle of the work hierarchy (Spell to Op to Target). Op in full.

Spell

A language/runtime adapter (e.g. go, md) that maps generic targets onto a toolchain's real commands. Spell in full.

Buzz

The language magusfiles are written in (the .buzz engine). Buzz in full.

Cache

The content-addressed store magus consults before running a target, so unchanged work is skipped. Cache in full.

Tool

An action a model can call through its host: a name, a description, a typed input and a result. magus serves its tools over MCP, each a read of the workspace model or a run of the CLI it already has. Tool in full.

Run

One target executing under one magus invocation, such as magus run test web or magus affected ci. A run keeps its captured output behind an output reference. Every magus run is a run whether or not any job asked for it; see Job for how the two relate. Run in full.

Conventions

Placeholders

Angle brackets mark a value you replace with your own; never type the brackets:

magus run <target>
magus completion <shell>    # e.g. bash, zsh, fish

<target>, <path>, <shell>, <name> and the like are stand-ins, not literal text.