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

MGS1031: a project's output is another project's source

One project declares a file as an output. A different project's source glob also claims it. Both declarations are individually reasonable, and together they arm a report that blames the wrong project.

[advice] output-is-another-projects-source: 11 declared output(s) are also another
project's source
    libs/testlayout/MAGUS.md is libs/testlayout's output and .'s source

Why it matters only later

Nothing misbehaves while the file's content is stable. The moment it changes:

  1. the owning project's generate rewrites it, which is exactly its job
  2. the claiming project is running a target that declared the same path as a source
  3. that target sees a declared input move underneath it and reports MGS4007 - an undeclared source mutation

The report is true about the write and wrong about the cause. The file is generated by definition, and the project named in the message never wrote it.

This is why the check is static. The conflict lives in the declarations, so it can be answered before anything runs - and it is present for as long as the two globs overlap, not only on the day some content drifts. In magus's own tree it sat on four projects' MAGUS.md files for as long as the markdown spell has claimed **/*.md, and only the one whose bytes went stale ever surfaced it.

What to do

Decide which project owns the file, then make the declarations say so:

  • Narrow the claiming glob. Usually right when the claim is incidental - a broad **/*.md from a spell sweeping up a nested project's generated index.
  • Move the file into the owning project's tree, if it is only claimed because of where it sits.
  • Leave it, deliberately. A file genuinely read by one project and written by another is a real relationship; declare the dependency so the ordering is explicit rather than incidental.

It is advice, not a failure, for the reason MGS1028 is: which project owns a file is the workspace's judgment, and a check that failed on it would be dictating a layout it cannot see the reasons for.

Exact paths only

The check compares an exact output path against the other project's globs. Whether two globs can overlap is not decidable in general - the same line MGS4002 draws - but whether a pattern matches one literal path is. An output declared as a pattern (dist/**) is not reported.

MGS1031magusfilesourcesoutputsgenerateddoctor
Last updated (407edfa7)
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.

Spell

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

CI

An ordinary magusfile-defined target you compose yourself with magus\needs - magus does not hardcode its stages. Magus.RunCI treats it specially only in that it strips the rw charm, it is the anchor magus affected ci keys off, and a selected scope with no project declaring it is a load error rather than a silent no-op. See targets.

MAGUS.md

The committed routing index at a workspace root, regenerated from the knowledge graph: it lists every node and points at the exact query for a given question, so it is the entry point an agent reads first. See knowledge.

Conventions

This page uses none of the site's convention markers. The full set is on the conventions page.