MGS1022: member only callable from a magusfile

A spell or a magus buzz script called a magus\* member that only a magusfile can serve.

[MGS1022] magus\project: only callable from a magusfile, not from a spell or a
  `magus buzz` script - it declares into the workspace magus is loading, and
  neither has one

import "magus" resolves everywhere Buzz runs, and most of the namespace works in a script or a spell. Two groups do not, for two different reasons.

Members that declare into a workspace

magus\project, magus\cache.remote, and magus\ci.provider record onto the registry magus builds while it loads a workspace. Evaluating a magusfile creates that registry. Nothing loads a script into a workspace, and a spell is loaded WHILE one is still being built, so a declaration made in either has nowhere to land.

There is no script-side equivalent, because there is nothing to declare. Put the declaration in the magusfile.buzz of the project it describes.

Members that read a loaded workspace

magus\describe.project, magus\affected, magus\graph, and magus\where answer from the workspace already open on the context, which is what makes them free of a subprocess. A script has no workspace open, and a spell runs before the one being loaded exists.

These do have an equivalent that works in both: the members that run a nested magus, which discovers the workspace root itself. From a spell, this is the only option; see authoring spells.

import "std";
import "magus";

fun main() > void !> any {
    // magus\describe.project() raises MGS1022 here; evaluatedProject forks and does not.
    foreach (p in magus\describe.evaluatedProject()) {
        std\print(p.path);
    }
}
main();

magus\cmd, magus\run, magus\insight, magus\doctor and the magus\describe methods that fork all work this way, and so does the rest of the namespace: magus\normalize, magus\describe.module, and the log levels (magus\info/debug/warn/error).

Resolution

Which fix applies depends on which group the member falls in.

A member that declares (magus\project, magus\cache.remote, magus\ci.provider) has no script-side equivalent, because there is nothing to declare. Move the call into the magusfile.buzz of the project it describes.

A member that reads a loaded workspace (magus\projects, magus\targets, magus\affected, magus\graph, magus\where) swaps for the member that runs a nested magus and finds the workspace root itself: magus\describe, magus\cmd, magus\run, magus\insight, magus\doctor. The example above is that substitution for magus\projects.

Why the import resolves at all

import "magus" used to fail outright in a script. You would read that as "there is no such module" and go looking for one that does not exist. Failing at the member instead names the rule you hit and leaves the rest of the namespace reachable, the way vcs\isDirty raises when no VCS is resolved while the vcs module stays where it is.

See also

• magus module: every member, and what each one needs.
• Debugging: the REPL, which does load a magusfile (magus buzz with no arguments).