set_waves ImportError: mapify_cli.dependency_graph unimportable from system python3 (uv-tool install layout)

[azalio]

Summary

map_orchestrator.py set_waves (and any other script-level function that needs mapify_cli.dependency_graph) fails with:

{"status": "error", "message": "Cannot import dependency_graph module"}

when .map/scripts/map_orchestrator.py is invoked with the system python3, on a machine where mapify-cli was installed via uv tool install (the standard install path per the CLI's own shebang).

Observed

• mapify_version: 3.20.0
• System python3 (/usr/local/bin/python3, 3.12.8) has no mapify_cli package installed — ModuleNotFoundError: No module named 'mapify_cli'.
• The actual package lives inside the isolated uv-tool venv: ~/.local/share/uv/tools/mapify-cli/lib/python3.12/site-packages/mapify_cli/dependency_graph.py, only importable via ~/.local/share/uv/tools/mapify-cli/bin/python3.
• map_orchestrator.py:2189-2217 has a fallback for the ImportError case: it walks Path(__file__).resolve().parents looking for src/mapify_cli/dependency_graph.py. That fallback only handles a source-checkout repo layout (e.g. running from a clone of map-framework itself). It does not handle the installed-package layout (uv tool / pipx / pip install), where there is no src/mapify_cli/ anywhere on disk relative to .map/scripts/.
• Net effect: any project where mapify-cli was installed via uv tool install mapify-cli (the tool's own recommended install method — see its console-script shebang #!.../uv/tools/mapify-cli/bin/python3) cannot run set_waves (and presumably any other orchestrator function needing dependency_graph) using the skill-documented invocation python3 .map/scripts/map_orchestrator.py ..., because python3 on PATH is unrelated to the venv mapify_cli was installed into.

Expected

set_waves (and other script-level orchestrator functions with this same import pattern) should work out of the box after mapify init, regardless of whether mapify-cli was installed via uv tool install, pipx install, or pip install into a venv, without requiring the caller to manually discover and invoke a different python3 binary.

file:line

.map/scripts/map_orchestrator.py:2189-2217 (the try/except ImportError fallback block in the function computing waves — the source-checkout-only path-walk fallback).

Possible fix directions (not prescriptive)

• Have mapify init write the resolved interpreter path (the one mapify_cli was actually installed into, e.g. via sys.executable at mapify init time) into a project-local config the generated scripts read, instead of assuming python3 on PATH.
• Or have the generated .map/scripts/*.py shebang/launcher resolve the same interpreter the mapify console script itself uses (e.g. locate it via shutil.which("mapify") and read its shebang) before falling back to plain python3.
• Or extend the existing ImportError fallback to also try importlib.metadata / common uv-tool and pipx venv locations (~/.local/share/uv/tools/mapify-cli/..., ~/.local/pipx/venvs/mapify-cli/...) in addition to the source-checkout src/mapify_cli/ walk.

Workaround used

Invoked the orchestrator with the uv-tool venv's own interpreter directly:

~/.local/share/uv/tools/mapify-cli/bin/python3 .map/scripts/map_orchestrator.py set_waves --blueprint .map/<branch>/blueprint.json