Skip to content

Question — manifest.json absolute paths + missing graphify-out/.gitignore: intended or oversight? #722

Open

Description

@gnrlbzik

Observation 1 — manifest.json paths

save_manifest() in graphify/detect.py (verified on 0.7.5, lines 760-771) writes file paths as dict keys (manifest[f] = {...}), where f originates from os.walk over the absolute root and is never relativized. Result: graphify-out/manifest.json contains entries like:

{
  "/Users/<name>/Projects/<repo>/packages/types/src/portfolio.ts": {
    "mtime": 1771971357.10,
    "hash": "3743c6e8a0c40024bccbaa7499cf547d"
  }
}

Note: graph.json source_file paths were relativized in 0.5.0, but the same change wasn't applied to manifest.json.

Observation 2 — no default .gitignore shipped

graphify-out/ is created on first run but contains a mix of:

  • Shareable artifacts — graph.json, GRAPH_REPORT.md, wiki/, cost.json, graph.html
  • Per-developer state — all of which contain absolute paths or per-machine values:
    • manifest.json — incremental detect cache (detect.py:save_manifest, absolute path keys + mtime + hash)
    • .graphify_root — saved scan-root (absolute path; __main__.py:1563, watch.py:133)
    • .graphify_incremental.json — incremental detect cache (absolute path keys)
    • .graphify_python — venv interpreter path (absolute)
    • .graphify_detect.json — transient detect output cache (absolute paths; __main__.py:1880)

Consumers must manually figure out which files are local-state vs. shareable, or end up tracking the wrong set. We hit this — manifest.json was committed and started leaking absolute /Users/<name>/... paths across the team.

Questions

  1. Is keeping absolute paths in manifest.json intended (e.g. cross-machine portability not a goal because it's local cache only)?
  2. If absolute paths aren't intended, would you accept a PR that relativizes manifest.json keys against the root, matching graph.json's 0.5.0 behavior?
  3. Would you consider shipping a default .gitignore (or README guidance) under graphify-out/ listing which files are local-state and shouldn't be committed? With five separate per-machine files, this is non-obvious without reading the source.

Happy to open a PR for either if intent is "oversight, fix accepted."

Environment

  • graphifyy 0.7.5
  • Python 3.13
  • Project layout: knowledge/graphify/.venv + graphify-out/ colocated under a project subdir

Activity

  1. gianlucapisati commented on Jun 4, 2026

    @gianlucapisati

    I've got the same question about the absolute path.
    It would be very useful to push these files to remote and share them with the team

  2. xuanswe commented on Jun 9, 2026

    @xuanswe

    Absolute paths are used everywhere:

    • git hooks: post-checkout, post-commit
    • GRAPTH_REPORT.md
    • graph.json
    • manifest.json
    • cache/*.json

    This prevents working in multiple machines or in a team :(.

    Claude Code suggests: gitignore graphify-out/ completely :(

  3. onionhammer commented on Jun 9, 2026

    @onionhammer

    Seems like kinda a critical issue given the git support this repo has

  4. edgarlepe commented on Jun 11, 2026

    @edgarlepe

    It looks like the library side of this was fixed by #1125 (for #777), but the shipped skill files never opt into it, so the default agent-driven pipeline still writes absolute-keyed manifests.

    save_manifest() / load_manifest() now accept root= and relativize keys. However, none of the bundled skill instructions pass it.

  5. pydentity commented on Jun 22, 2026

    @pydentity

    It's even worse:
    I renamed the dir of my repo. After a while I ran a /graphify update. It rescanned the whole repo and now I have all files duplicated in my manifest.json. Version 0.8.39.

    How is sharability/portability of generated graphs not a number 1 priority? Absolutely baffling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions