magus v0.4.2 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 (9edeede5)
Earlier changes on this page (2)

Full history ↗ · Blame source ↗

Glossary

Workspace

The magus root directory that owns a set of projects and shared config; the unit magus operates over. See workspace.

Project

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

Magusfile

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

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. See targets.

Op

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

Spell

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

Buzz

The language magusfiles are written in (the .buzz engine). See engines.

Cache

The content-addressed store magus consults before running a target, so unchanged work is skipped. See cache.

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.