codemarp 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- codemarp-0.1.0/PKG-INFO +358 -0
- codemarp-0.1.0/README.md +349 -0
- codemarp-0.1.0/pyproject.toml +25 -0
- codemarp-0.1.0/setup.cfg +4 -0
- codemarp-0.1.0/src/codemarp/__init__.py +1 -0
- codemarp-0.1.0/src/codemarp/analyzers/__init__.py +1 -0
- codemarp-0.1.0/src/codemarp/analyzers/high_level.py +77 -0
- codemarp-0.1.0/src/codemarp/analyzers/low_level.py +272 -0
- codemarp-0.1.0/src/codemarp/analyzers/mid_level.py +162 -0
- codemarp-0.1.0/src/codemarp/cli/__init__.py +1 -0
- codemarp-0.1.0/src/codemarp/cli/main.py +159 -0
- codemarp-0.1.0/src/codemarp/errors.py +22 -0
- codemarp-0.1.0/src/codemarp/exporters/__init__.py +1 -0
- codemarp-0.1.0/src/codemarp/exporters/json_exporter.py +9 -0
- codemarp-0.1.0/src/codemarp/exporters/mermaid.py +116 -0
- codemarp-0.1.0/src/codemarp/graph/__init__.py +1 -0
- codemarp-0.1.0/src/codemarp/graph/builder.py +39 -0
- codemarp-0.1.0/src/codemarp/graph/models.py +71 -0
- codemarp-0.1.0/src/codemarp/parser/__init__.py +1 -0
- codemarp-0.1.0/src/codemarp/parser/js_parser.py +3 -0
- codemarp-0.1.0/src/codemarp/parser/python_parser.py +282 -0
- codemarp-0.1.0/src/codemarp/pipeline/apply_view.py +40 -0
- codemarp-0.1.0/src/codemarp/pipeline/build_bundle.py +54 -0
- codemarp-0.1.0/src/codemarp/pipeline/export_all.py +80 -0
- codemarp-0.1.0/src/codemarp/views/module_view.py +16 -0
- codemarp-0.1.0/src/codemarp/views/subgraph.py +27 -0
- codemarp-0.1.0/src/codemarp/views/trace.py +96 -0
- codemarp-0.1.0/src/codemarp.egg-info/PKG-INFO +358 -0
- codemarp-0.1.0/src/codemarp.egg-info/SOURCES.txt +44 -0
- codemarp-0.1.0/src/codemarp.egg-info/dependency_links.txt +1 -0
- codemarp-0.1.0/src/codemarp.egg-info/entry_points.txt +2 -0
- codemarp-0.1.0/src/codemarp.egg-info/requires.txt +3 -0
- codemarp-0.1.0/src/codemarp.egg-info/top_level.txt +1 -0
- codemarp-0.1.0/tests/test_cli_smoke.py +141 -0
- codemarp-0.1.0/tests/test_cli_view_validation.py +141 -0
- codemarp-0.1.0/tests/test_high_level.py +138 -0
- codemarp-0.1.0/tests/test_low_level_cfg.py +154 -0
- codemarp-0.1.0/tests/test_low_level_export.py +26 -0
- codemarp-0.1.0/tests/test_low_level_lookup.py +80 -0
- codemarp-0.1.0/tests/test_mid_level_resolution.py +164 -0
- codemarp-0.1.0/tests/test_module_view.py +50 -0
- codemarp-0.1.0/tests/test_phase1_smoke.py +25 -0
- codemarp-0.1.0/tests/test_pipeline.py +105 -0
- codemarp-0.1.0/tests/test_python_parser.py +31 -0
- codemarp-0.1.0/tests/test_reverse_trace.py +100 -0
- codemarp-0.1.0/tests/test_trace.py +52 -0
codemarp-0.1.0/PKG-INFO
ADDED
|
@@ -0,0 +1,358 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: codemarp
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: Multi-level code architecture and relationship mapping
|
|
5
|
+
Requires-Python: >=3.12
|
|
6
|
+
Description-Content-Type: text/markdown
|
|
7
|
+
Provides-Extra: dev
|
|
8
|
+
Requires-Dist: pytest>=9.0.3; extra == "dev"
|
|
9
|
+
|
|
10
|
+
# CodeMarp
|
|
11
|
+
|
|
12
|
+
**Multi-level code architecture and relationship mapping**
|
|
13
|
+
|
|
14
|
+
> Understand a codebase like a map — zoom in, zoom out, follow the flow.
|
|
15
|
+
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
## The problem
|
|
19
|
+
|
|
20
|
+
Large codebases are hard to navigate. You open a file and you're already lost. You don't know what calls what, where things live, or what actually happens inside a function.
|
|
21
|
+
|
|
22
|
+
Documentation is outdated. Diagrams don't exist. The only way to understand the code is to read all of it.
|
|
23
|
+
|
|
24
|
+
CodeMarp takes a different approach: it builds the map for you.
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## What CodeMarp does
|
|
28
|
+
|
|
29
|
+
Given a Python repository, CodeMarp gives you three zoom levels:
|
|
30
|
+
|
|
31
|
+
| Level | What you see |
|
|
32
|
+
|-------|-------------|
|
|
33
|
+
| **High** | Module and package architecture — how things are organised |
|
|
34
|
+
| **Mid** | Function relationships — who calls what |
|
|
35
|
+
| **Low** | Control flow inside a function — what actually happens |
|
|
36
|
+
|
|
37
|
+
Think of it as **Google Maps for your codebase**. Built entirely from static analysis — no runtime, no instrumentation.
|
|
38
|
+
|
|
39
|
+
Zoom out to see the city. Zoom in to see the streets. Zoom in further to see the building layout.
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## Output
|
|
44
|
+
|
|
45
|
+
Every analysis produces:
|
|
46
|
+
|
|
47
|
+
```
|
|
48
|
+
out/
|
|
49
|
+
high_level.mmd # architecture graph
|
|
50
|
+
mid_level.mmd # function call graph
|
|
51
|
+
low_level.mmd # control flow (when using --view low)
|
|
52
|
+
graph.json # full graph data for tooling
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
- **Mermaid** (`.mmd`) — renders in GitHub, VS Code, Mermaid Live Editor
|
|
56
|
+
- **JSON** — for tooling, integrations, and future UI
|
|
57
|
+
|
|
58
|
+
---
|
|
59
|
+
|
|
60
|
+
## Install
|
|
61
|
+
|
|
62
|
+
For local development in this repo:
|
|
63
|
+
|
|
64
|
+
```bash
|
|
65
|
+
uv sync --extra dev
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
To install in a project environment:
|
|
69
|
+
|
|
70
|
+
```bash
|
|
71
|
+
uv pip install codemarp
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
Or with pip:
|
|
75
|
+
|
|
76
|
+
```bash
|
|
77
|
+
pip install codemarp
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
---
|
|
81
|
+
|
|
82
|
+
## Usage
|
|
83
|
+
|
|
84
|
+
### Analyse a repo
|
|
85
|
+
|
|
86
|
+
```bash
|
|
87
|
+
codemarp analyze path/to/repo --out out
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
Point at the folder that **contains your top-level package**:
|
|
91
|
+
|
|
92
|
+
```bash
|
|
93
|
+
# flat layout: mypackage/ is at root
|
|
94
|
+
codemarp analyze .
|
|
95
|
+
|
|
96
|
+
# src layout: mypackage/ is inside src/
|
|
97
|
+
codemarp analyze src
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
---
|
|
101
|
+
|
|
102
|
+
### Views
|
|
103
|
+
|
|
104
|
+
#### Full (default)
|
|
105
|
+
See the entire graph — architecture + all function relationships.
|
|
106
|
+
|
|
107
|
+
```bash
|
|
108
|
+
codemarp analyze path/to/repo --view full --out out
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
#### Trace — what does this function call?
|
|
112
|
+
Follow a function forward through the call graph.
|
|
113
|
+
|
|
114
|
+
```bash
|
|
115
|
+
codemarp analyze path/to/repo \
|
|
116
|
+
--view trace \
|
|
117
|
+
--focus package.module:function_name \
|
|
118
|
+
--max-depth 3 \
|
|
119
|
+
--out out
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
#### Reverse — what calls this function?
|
|
123
|
+
Find every path that leads to a function.
|
|
124
|
+
|
|
125
|
+
```bash
|
|
126
|
+
codemarp analyze path/to/repo \
|
|
127
|
+
--view reverse \
|
|
128
|
+
--focus package.module:function_name \
|
|
129
|
+
--max-depth 3 \
|
|
130
|
+
--out out
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
#### Module — zoom into one module
|
|
134
|
+
Show the functions and internal relationships for a single module.
|
|
135
|
+
|
|
136
|
+
```bash
|
|
137
|
+
codemarp analyze path/to/repo \
|
|
138
|
+
--view module \
|
|
139
|
+
--module package.module_name \
|
|
140
|
+
--out out
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
#### Low — what happens inside this function?
|
|
144
|
+
Build a control-flow graph for one function.
|
|
145
|
+
|
|
146
|
+
```bash
|
|
147
|
+
codemarp analyze path/to/repo \
|
|
148
|
+
--view low \
|
|
149
|
+
--focus package.module:function_name \
|
|
150
|
+
--out out
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
---
|
|
154
|
+
|
|
155
|
+
## Typical workflow
|
|
156
|
+
|
|
157
|
+
```
|
|
158
|
+
1. codemarp analyze src --view full
|
|
159
|
+
→ understand the overall structure
|
|
160
|
+
|
|
161
|
+
2. codemarp analyze src --view module --module mypackage.core
|
|
162
|
+
→ inspect one area
|
|
163
|
+
|
|
164
|
+
3. codemarp analyze src --view trace --focus mypackage.core:run --max-depth 3
|
|
165
|
+
→ follow a specific entrypoint
|
|
166
|
+
|
|
167
|
+
4. codemarp analyze src --view low --focus mypackage.core:run
|
|
168
|
+
→ zoom into the logic
|
|
169
|
+
```
|
|
170
|
+
|
|
171
|
+
---
|
|
172
|
+
|
|
173
|
+
## Viewing the output
|
|
174
|
+
|
|
175
|
+
Mermaid files render automatically in:
|
|
176
|
+
|
|
177
|
+
- **GitHub** — renders Mermaid blocks directly in Markdown files
|
|
178
|
+
- **[Mermaid Live Editor](https://mermaid.live)** — paste and share
|
|
179
|
+
- **VS Code** — with the Mermaid Preview extension
|
|
180
|
+
|
|
181
|
+
Yes, GitHub renders Mermaid blocks directly in Markdown, so the sample diagrams below should display in the repo README.
|
|
182
|
+
|
|
183
|
+
---
|
|
184
|
+
|
|
185
|
+
## Sample output
|
|
186
|
+
|
|
187
|
+
These examples were generated from the CodeMarp codebase itself.
|
|
188
|
+
|
|
189
|
+
### High-level architecture
|
|
190
|
+
|
|
191
|
+
Command:
|
|
192
|
+
|
|
193
|
+
```bash
|
|
194
|
+
codemarp analyze src --view full --out samples/codemarp_full_out
|
|
195
|
+
```
|
|
196
|
+
|
|
197
|
+
Excerpt from [`samples/codemarp_full_out/high_level.mmd`](samples/codemarp_full_out/high_level.mmd):
|
|
198
|
+
|
|
199
|
+
```mermaid
|
|
200
|
+
flowchart LR
|
|
201
|
+
codemarp_analyzers["codemarp.analyzers"]
|
|
202
|
+
codemarp_cli["codemarp.cli"]
|
|
203
|
+
codemarp_errors(["codemarp.errors"])
|
|
204
|
+
codemarp_exporters["codemarp.exporters"]
|
|
205
|
+
codemarp_graph["codemarp.graph"]
|
|
206
|
+
codemarp_parser["codemarp.parser"]
|
|
207
|
+
codemarp_pipeline["codemarp.pipeline"]
|
|
208
|
+
codemarp_views["codemarp.views"]
|
|
209
|
+
codemarp_analyzers -->|imports| codemarp_graph
|
|
210
|
+
codemarp_analyzers -->|imports| codemarp_parser
|
|
211
|
+
codemarp_cli -->|imports| codemarp_analyzers
|
|
212
|
+
codemarp_cli -->|imports| codemarp_errors
|
|
213
|
+
codemarp_cli -->|imports| codemarp_pipeline
|
|
214
|
+
codemarp_exporters -->|imports| codemarp_graph
|
|
215
|
+
codemarp_exporters -->|imports| codemarp_analyzers
|
|
216
|
+
codemarp_parser -->|imports| codemarp_errors
|
|
217
|
+
codemarp_parser -->|imports| codemarp_graph
|
|
218
|
+
codemarp_pipeline -->|imports| codemarp_graph
|
|
219
|
+
codemarp_pipeline -->|imports| codemarp_views
|
|
220
|
+
codemarp_pipeline -->|imports| codemarp_analyzers
|
|
221
|
+
codemarp_pipeline -->|imports| codemarp_parser
|
|
222
|
+
codemarp_pipeline -->|imports| codemarp_exporters
|
|
223
|
+
codemarp_views -->|imports| codemarp_errors
|
|
224
|
+
codemarp_views -->|imports| codemarp_graph
|
|
225
|
+
```
|
|
226
|
+
|
|
227
|
+
This is the zoomed-out package view: which parts of the project depend on which others.
|
|
228
|
+
|
|
229
|
+
### Focused function trace
|
|
230
|
+
|
|
231
|
+
Command:
|
|
232
|
+
|
|
233
|
+
```bash
|
|
234
|
+
codemarp analyze src --focus codemarp.cli.main:analyze_command --out out
|
|
235
|
+
```
|
|
236
|
+
|
|
237
|
+
Excerpt from [`samples/codemarp_trace_out/mid_level.mmd`](samples/codemarp_trace_out/mid_level.mmd):
|
|
238
|
+
|
|
239
|
+
```mermaid
|
|
240
|
+
flowchart LR
|
|
241
|
+
codemarp_graph_models_GraphBundle_function_by_id["codemarp.graph.models:GraphBundle.function_by_id"]
|
|
242
|
+
codemarp_views_subgraph_build_function_subgraph["codemarp.views.subgraph:build_function_subgraph"]
|
|
243
|
+
codemarp_views_subgraph__filter_edges_for_nodes["codemarp.views.subgraph:_filter_edges_for_nodes"]
|
|
244
|
+
codemarp_views_subgraph__modules_for_functions["codemarp.views.subgraph:_modules_for_functions"]
|
|
245
|
+
codemarp_views_trace__build_call_adjacency["codemarp.views.trace:_build_call_adjacency"]
|
|
246
|
+
codemarp_views_trace_trace_functions_forward["codemarp.views.trace:trace_functions_forward"]
|
|
247
|
+
codemarp_views_trace_trace_function_view["codemarp.views.trace:trace_function_view"]
|
|
248
|
+
codemarp_views_trace__validate_entrypoint["codemarp.views.trace:_validate_entrypoint"]
|
|
249
|
+
codemarp_views_subgraph_build_function_subgraph -->|calls| codemarp_views_subgraph__modules_for_functions
|
|
250
|
+
codemarp_views_subgraph_build_function_subgraph -->|calls| codemarp_views_subgraph__filter_edges_for_nodes
|
|
251
|
+
codemarp_views_trace_trace_functions_forward -->|calls| codemarp_views_trace__validate_entrypoint
|
|
252
|
+
codemarp_views_trace_trace_functions_forward -->|calls| codemarp_views_trace__build_call_adjacency
|
|
253
|
+
codemarp_views_trace_trace_function_view -->|calls| codemarp_views_trace__validate_entrypoint
|
|
254
|
+
codemarp_views_trace_trace_function_view -->|calls| codemarp_views_trace_trace_functions_forward
|
|
255
|
+
codemarp_views_trace_trace_function_view -->|calls| codemarp_views_subgraph_build_function_subgraph
|
|
256
|
+
codemarp_views_trace__validate_entrypoint -->|calls| codemarp_graph_models_GraphBundle_function_by_id
|
|
257
|
+
```
|
|
258
|
+
|
|
259
|
+
This is the focused mid-level view: starting from one function, you can follow the call chain it reaches.
|
|
260
|
+
|
|
261
|
+
### Low-level control flow
|
|
262
|
+
|
|
263
|
+
Command:
|
|
264
|
+
|
|
265
|
+
```bash
|
|
266
|
+
codemarp analyze src --view low --focus codemarp.parser.python_parser:get_source --out out
|
|
267
|
+
```
|
|
268
|
+
|
|
269
|
+
Excerpt from [`samples/codemarp_low_out/low_level.mmd`](samples/codemarp_low_out/low_level.mmd):
|
|
270
|
+
|
|
271
|
+
```mermaid
|
|
272
|
+
flowchart TD
|
|
273
|
+
n1(["Start"]):::terminal
|
|
274
|
+
n2{"encoding is None"}:::decision
|
|
275
|
+
n3["get_best_encoding(...)"]:::statement
|
|
276
|
+
n4["Merge"]:::merge
|
|
277
|
+
n5{"errors is None"}:::decision
|
|
278
|
+
n6["Assign"]:::statement
|
|
279
|
+
n7["Merge"]:::merge
|
|
280
|
+
n8(["Return"]):::terminal
|
|
281
|
+
n9(["End"]):::terminal
|
|
282
|
+
n1 --> n2
|
|
283
|
+
n2 -->|True| n3
|
|
284
|
+
n3 --> n4
|
|
285
|
+
n2 -->|False| n4
|
|
286
|
+
n4 --> n5
|
|
287
|
+
n5 -->|True| n6
|
|
288
|
+
n6 --> n7
|
|
289
|
+
n5 -->|False| n7
|
|
290
|
+
n7 --> n8
|
|
291
|
+
n8 --> n9
|
|
292
|
+
|
|
293
|
+
classDef decision fill:#fff3cd,stroke:#d4a017,color:#000;
|
|
294
|
+
classDef statement fill:#f0f0f0,stroke:#aaa,color:#333;
|
|
295
|
+
classDef terminal fill:#fde8e8,stroke:#c0392b,color:#000;
|
|
296
|
+
classDef merge fill:#eef2ff,stroke:#7c8fdb,color:#000;
|
|
297
|
+
classDef start fill:#e8f5e9,stroke:#2e7d32,color:#000;
|
|
298
|
+
```
|
|
299
|
+
|
|
300
|
+
This is the zoomed-in function view: branches, merges, and return flow inside a single function.
|
|
301
|
+
|
|
302
|
+
---
|
|
303
|
+
|
|
304
|
+
## Known limitations
|
|
305
|
+
|
|
306
|
+
CodeMarp is static analysis — it reads your code without running it.
|
|
307
|
+
|
|
308
|
+
| Limitation | Workaround |
|
|
309
|
+
|-----------|------------|
|
|
310
|
+
| Relative imports may produce sparse high-level graphs | Use `--view module` or `--view trace` instead |
|
|
311
|
+
| Method calls (`self.method()`) are conservatively handled | Some valid edges may be missing, but false positives are reduced |
|
|
312
|
+
| Dynamic dispatch is not tracked | Results reflect static structure only |
|
|
313
|
+
| Large full graphs can be hard to read | Use focused views — `trace`, `module`, `reverse` |
|
|
314
|
+
|
|
315
|
+
These are honest limitations, not bugs. Focused views exist precisely because full graphs on real codebases get noisy.
|
|
316
|
+
|
|
317
|
+
---
|
|
318
|
+
|
|
319
|
+
## Roadmap
|
|
320
|
+
|
|
321
|
+
- Better call resolution (method dispatch, aliases)
|
|
322
|
+
- Graph filtering and noise reduction
|
|
323
|
+
- Tree-sitter migration → multi-language support
|
|
324
|
+
- JavaScript / TypeScript support
|
|
325
|
+
- Interactive web UI
|
|
326
|
+
|
|
327
|
+
---
|
|
328
|
+
|
|
329
|
+
## Philosophy
|
|
330
|
+
|
|
331
|
+
**Useful before perfect.**
|
|
332
|
+
CodeMarp v0.1 is not exhaustive. It is correct for common cases and honest about where it isn't.
|
|
333
|
+
|
|
334
|
+
**Readable before complete.**
|
|
335
|
+
A graph you can understand is more valuable than a graph that shows everything.
|
|
336
|
+
|
|
337
|
+
**Static first.**
|
|
338
|
+
No runtime instrumentation. No code execution. Analysis runs anywhere.
|
|
339
|
+
|
|
340
|
+
---
|
|
341
|
+
|
|
342
|
+
## Status
|
|
343
|
+
|
|
344
|
+
- Python only (AST-based, tree-sitter planned)
|
|
345
|
+
- CLI-first
|
|
346
|
+
- v0.1.0 — early but usable on real codebases
|
|
347
|
+
|
|
348
|
+
---
|
|
349
|
+
|
|
350
|
+
## Name
|
|
351
|
+
|
|
352
|
+
**CodeMarp** — sounds like "code map", because that's what it produces.
|
|
353
|
+
|
|
354
|
+
If you want an expansion: *Code Mapping, Architecture, Relationships, and Paths*
|
|
355
|
+
|
|
356
|
+
---
|
|
357
|
+
|
|
358
|
+
*Built to answer the question every developer asks when they open an unfamiliar codebase: where do I even start?*
|
codemarp-0.1.0/README.md
ADDED
|
@@ -0,0 +1,349 @@
|
|
|
1
|
+
# CodeMarp
|
|
2
|
+
|
|
3
|
+
**Multi-level code architecture and relationship mapping**
|
|
4
|
+
|
|
5
|
+
> Understand a codebase like a map — zoom in, zoom out, follow the flow.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## The problem
|
|
10
|
+
|
|
11
|
+
Large codebases are hard to navigate. You open a file and you're already lost. You don't know what calls what, where things live, or what actually happens inside a function.
|
|
12
|
+
|
|
13
|
+
Documentation is outdated. Diagrams don't exist. The only way to understand the code is to read all of it.
|
|
14
|
+
|
|
15
|
+
CodeMarp takes a different approach: it builds the map for you.
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
## What CodeMarp does
|
|
19
|
+
|
|
20
|
+
Given a Python repository, CodeMarp gives you three zoom levels:
|
|
21
|
+
|
|
22
|
+
| Level | What you see |
|
|
23
|
+
|-------|-------------|
|
|
24
|
+
| **High** | Module and package architecture — how things are organised |
|
|
25
|
+
| **Mid** | Function relationships — who calls what |
|
|
26
|
+
| **Low** | Control flow inside a function — what actually happens |
|
|
27
|
+
|
|
28
|
+
Think of it as **Google Maps for your codebase**. Built entirely from static analysis — no runtime, no instrumentation.
|
|
29
|
+
|
|
30
|
+
Zoom out to see the city. Zoom in to see the streets. Zoom in further to see the building layout.
|
|
31
|
+
|
|
32
|
+
---
|
|
33
|
+
|
|
34
|
+
## Output
|
|
35
|
+
|
|
36
|
+
Every analysis produces:
|
|
37
|
+
|
|
38
|
+
```
|
|
39
|
+
out/
|
|
40
|
+
high_level.mmd # architecture graph
|
|
41
|
+
mid_level.mmd # function call graph
|
|
42
|
+
low_level.mmd # control flow (when using --view low)
|
|
43
|
+
graph.json # full graph data for tooling
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
- **Mermaid** (`.mmd`) — renders in GitHub, VS Code, Mermaid Live Editor
|
|
47
|
+
- **JSON** — for tooling, integrations, and future UI
|
|
48
|
+
|
|
49
|
+
---
|
|
50
|
+
|
|
51
|
+
## Install
|
|
52
|
+
|
|
53
|
+
For local development in this repo:
|
|
54
|
+
|
|
55
|
+
```bash
|
|
56
|
+
uv sync --extra dev
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
To install in a project environment:
|
|
60
|
+
|
|
61
|
+
```bash
|
|
62
|
+
uv pip install codemarp
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
Or with pip:
|
|
66
|
+
|
|
67
|
+
```bash
|
|
68
|
+
pip install codemarp
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
## Usage
|
|
74
|
+
|
|
75
|
+
### Analyse a repo
|
|
76
|
+
|
|
77
|
+
```bash
|
|
78
|
+
codemarp analyze path/to/repo --out out
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
Point at the folder that **contains your top-level package**:
|
|
82
|
+
|
|
83
|
+
```bash
|
|
84
|
+
# flat layout: mypackage/ is at root
|
|
85
|
+
codemarp analyze .
|
|
86
|
+
|
|
87
|
+
# src layout: mypackage/ is inside src/
|
|
88
|
+
codemarp analyze src
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
---
|
|
92
|
+
|
|
93
|
+
### Views
|
|
94
|
+
|
|
95
|
+
#### Full (default)
|
|
96
|
+
See the entire graph — architecture + all function relationships.
|
|
97
|
+
|
|
98
|
+
```bash
|
|
99
|
+
codemarp analyze path/to/repo --view full --out out
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
#### Trace — what does this function call?
|
|
103
|
+
Follow a function forward through the call graph.
|
|
104
|
+
|
|
105
|
+
```bash
|
|
106
|
+
codemarp analyze path/to/repo \
|
|
107
|
+
--view trace \
|
|
108
|
+
--focus package.module:function_name \
|
|
109
|
+
--max-depth 3 \
|
|
110
|
+
--out out
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
#### Reverse — what calls this function?
|
|
114
|
+
Find every path that leads to a function.
|
|
115
|
+
|
|
116
|
+
```bash
|
|
117
|
+
codemarp analyze path/to/repo \
|
|
118
|
+
--view reverse \
|
|
119
|
+
--focus package.module:function_name \
|
|
120
|
+
--max-depth 3 \
|
|
121
|
+
--out out
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
#### Module — zoom into one module
|
|
125
|
+
Show the functions and internal relationships for a single module.
|
|
126
|
+
|
|
127
|
+
```bash
|
|
128
|
+
codemarp analyze path/to/repo \
|
|
129
|
+
--view module \
|
|
130
|
+
--module package.module_name \
|
|
131
|
+
--out out
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
#### Low — what happens inside this function?
|
|
135
|
+
Build a control-flow graph for one function.
|
|
136
|
+
|
|
137
|
+
```bash
|
|
138
|
+
codemarp analyze path/to/repo \
|
|
139
|
+
--view low \
|
|
140
|
+
--focus package.module:function_name \
|
|
141
|
+
--out out
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
---
|
|
145
|
+
|
|
146
|
+
## Typical workflow
|
|
147
|
+
|
|
148
|
+
```
|
|
149
|
+
1. codemarp analyze src --view full
|
|
150
|
+
→ understand the overall structure
|
|
151
|
+
|
|
152
|
+
2. codemarp analyze src --view module --module mypackage.core
|
|
153
|
+
→ inspect one area
|
|
154
|
+
|
|
155
|
+
3. codemarp analyze src --view trace --focus mypackage.core:run --max-depth 3
|
|
156
|
+
→ follow a specific entrypoint
|
|
157
|
+
|
|
158
|
+
4. codemarp analyze src --view low --focus mypackage.core:run
|
|
159
|
+
→ zoom into the logic
|
|
160
|
+
```
|
|
161
|
+
|
|
162
|
+
---
|
|
163
|
+
|
|
164
|
+
## Viewing the output
|
|
165
|
+
|
|
166
|
+
Mermaid files render automatically in:
|
|
167
|
+
|
|
168
|
+
- **GitHub** — renders Mermaid blocks directly in Markdown files
|
|
169
|
+
- **[Mermaid Live Editor](https://mermaid.live)** — paste and share
|
|
170
|
+
- **VS Code** — with the Mermaid Preview extension
|
|
171
|
+
|
|
172
|
+
Yes, GitHub renders Mermaid blocks directly in Markdown, so the sample diagrams below should display in the repo README.
|
|
173
|
+
|
|
174
|
+
---
|
|
175
|
+
|
|
176
|
+
## Sample output
|
|
177
|
+
|
|
178
|
+
These examples were generated from the CodeMarp codebase itself.
|
|
179
|
+
|
|
180
|
+
### High-level architecture
|
|
181
|
+
|
|
182
|
+
Command:
|
|
183
|
+
|
|
184
|
+
```bash
|
|
185
|
+
codemarp analyze src --view full --out samples/codemarp_full_out
|
|
186
|
+
```
|
|
187
|
+
|
|
188
|
+
Excerpt from [`samples/codemarp_full_out/high_level.mmd`](samples/codemarp_full_out/high_level.mmd):
|
|
189
|
+
|
|
190
|
+
```mermaid
|
|
191
|
+
flowchart LR
|
|
192
|
+
codemarp_analyzers["codemarp.analyzers"]
|
|
193
|
+
codemarp_cli["codemarp.cli"]
|
|
194
|
+
codemarp_errors(["codemarp.errors"])
|
|
195
|
+
codemarp_exporters["codemarp.exporters"]
|
|
196
|
+
codemarp_graph["codemarp.graph"]
|
|
197
|
+
codemarp_parser["codemarp.parser"]
|
|
198
|
+
codemarp_pipeline["codemarp.pipeline"]
|
|
199
|
+
codemarp_views["codemarp.views"]
|
|
200
|
+
codemarp_analyzers -->|imports| codemarp_graph
|
|
201
|
+
codemarp_analyzers -->|imports| codemarp_parser
|
|
202
|
+
codemarp_cli -->|imports| codemarp_analyzers
|
|
203
|
+
codemarp_cli -->|imports| codemarp_errors
|
|
204
|
+
codemarp_cli -->|imports| codemarp_pipeline
|
|
205
|
+
codemarp_exporters -->|imports| codemarp_graph
|
|
206
|
+
codemarp_exporters -->|imports| codemarp_analyzers
|
|
207
|
+
codemarp_parser -->|imports| codemarp_errors
|
|
208
|
+
codemarp_parser -->|imports| codemarp_graph
|
|
209
|
+
codemarp_pipeline -->|imports| codemarp_graph
|
|
210
|
+
codemarp_pipeline -->|imports| codemarp_views
|
|
211
|
+
codemarp_pipeline -->|imports| codemarp_analyzers
|
|
212
|
+
codemarp_pipeline -->|imports| codemarp_parser
|
|
213
|
+
codemarp_pipeline -->|imports| codemarp_exporters
|
|
214
|
+
codemarp_views -->|imports| codemarp_errors
|
|
215
|
+
codemarp_views -->|imports| codemarp_graph
|
|
216
|
+
```
|
|
217
|
+
|
|
218
|
+
This is the zoomed-out package view: which parts of the project depend on which others.
|
|
219
|
+
|
|
220
|
+
### Focused function trace
|
|
221
|
+
|
|
222
|
+
Command:
|
|
223
|
+
|
|
224
|
+
```bash
|
|
225
|
+
codemarp analyze src --focus codemarp.cli.main:analyze_command --out out
|
|
226
|
+
```
|
|
227
|
+
|
|
228
|
+
Excerpt from [`samples/codemarp_trace_out/mid_level.mmd`](samples/codemarp_trace_out/mid_level.mmd):
|
|
229
|
+
|
|
230
|
+
```mermaid
|
|
231
|
+
flowchart LR
|
|
232
|
+
codemarp_graph_models_GraphBundle_function_by_id["codemarp.graph.models:GraphBundle.function_by_id"]
|
|
233
|
+
codemarp_views_subgraph_build_function_subgraph["codemarp.views.subgraph:build_function_subgraph"]
|
|
234
|
+
codemarp_views_subgraph__filter_edges_for_nodes["codemarp.views.subgraph:_filter_edges_for_nodes"]
|
|
235
|
+
codemarp_views_subgraph__modules_for_functions["codemarp.views.subgraph:_modules_for_functions"]
|
|
236
|
+
codemarp_views_trace__build_call_adjacency["codemarp.views.trace:_build_call_adjacency"]
|
|
237
|
+
codemarp_views_trace_trace_functions_forward["codemarp.views.trace:trace_functions_forward"]
|
|
238
|
+
codemarp_views_trace_trace_function_view["codemarp.views.trace:trace_function_view"]
|
|
239
|
+
codemarp_views_trace__validate_entrypoint["codemarp.views.trace:_validate_entrypoint"]
|
|
240
|
+
codemarp_views_subgraph_build_function_subgraph -->|calls| codemarp_views_subgraph__modules_for_functions
|
|
241
|
+
codemarp_views_subgraph_build_function_subgraph -->|calls| codemarp_views_subgraph__filter_edges_for_nodes
|
|
242
|
+
codemarp_views_trace_trace_functions_forward -->|calls| codemarp_views_trace__validate_entrypoint
|
|
243
|
+
codemarp_views_trace_trace_functions_forward -->|calls| codemarp_views_trace__build_call_adjacency
|
|
244
|
+
codemarp_views_trace_trace_function_view -->|calls| codemarp_views_trace__validate_entrypoint
|
|
245
|
+
codemarp_views_trace_trace_function_view -->|calls| codemarp_views_trace_trace_functions_forward
|
|
246
|
+
codemarp_views_trace_trace_function_view -->|calls| codemarp_views_subgraph_build_function_subgraph
|
|
247
|
+
codemarp_views_trace__validate_entrypoint -->|calls| codemarp_graph_models_GraphBundle_function_by_id
|
|
248
|
+
```
|
|
249
|
+
|
|
250
|
+
This is the focused mid-level view: starting from one function, you can follow the call chain it reaches.
|
|
251
|
+
|
|
252
|
+
### Low-level control flow
|
|
253
|
+
|
|
254
|
+
Command:
|
|
255
|
+
|
|
256
|
+
```bash
|
|
257
|
+
codemarp analyze src --view low --focus codemarp.parser.python_parser:get_source --out out
|
|
258
|
+
```
|
|
259
|
+
|
|
260
|
+
Excerpt from [`samples/codemarp_low_out/low_level.mmd`](samples/codemarp_low_out/low_level.mmd):
|
|
261
|
+
|
|
262
|
+
```mermaid
|
|
263
|
+
flowchart TD
|
|
264
|
+
n1(["Start"]):::terminal
|
|
265
|
+
n2{"encoding is None"}:::decision
|
|
266
|
+
n3["get_best_encoding(...)"]:::statement
|
|
267
|
+
n4["Merge"]:::merge
|
|
268
|
+
n5{"errors is None"}:::decision
|
|
269
|
+
n6["Assign"]:::statement
|
|
270
|
+
n7["Merge"]:::merge
|
|
271
|
+
n8(["Return"]):::terminal
|
|
272
|
+
n9(["End"]):::terminal
|
|
273
|
+
n1 --> n2
|
|
274
|
+
n2 -->|True| n3
|
|
275
|
+
n3 --> n4
|
|
276
|
+
n2 -->|False| n4
|
|
277
|
+
n4 --> n5
|
|
278
|
+
n5 -->|True| n6
|
|
279
|
+
n6 --> n7
|
|
280
|
+
n5 -->|False| n7
|
|
281
|
+
n7 --> n8
|
|
282
|
+
n8 --> n9
|
|
283
|
+
|
|
284
|
+
classDef decision fill:#fff3cd,stroke:#d4a017,color:#000;
|
|
285
|
+
classDef statement fill:#f0f0f0,stroke:#aaa,color:#333;
|
|
286
|
+
classDef terminal fill:#fde8e8,stroke:#c0392b,color:#000;
|
|
287
|
+
classDef merge fill:#eef2ff,stroke:#7c8fdb,color:#000;
|
|
288
|
+
classDef start fill:#e8f5e9,stroke:#2e7d32,color:#000;
|
|
289
|
+
```
|
|
290
|
+
|
|
291
|
+
This is the zoomed-in function view: branches, merges, and return flow inside a single function.
|
|
292
|
+
|
|
293
|
+
---
|
|
294
|
+
|
|
295
|
+
## Known limitations
|
|
296
|
+
|
|
297
|
+
CodeMarp is static analysis — it reads your code without running it.
|
|
298
|
+
|
|
299
|
+
| Limitation | Workaround |
|
|
300
|
+
|-----------|------------|
|
|
301
|
+
| Relative imports may produce sparse high-level graphs | Use `--view module` or `--view trace` instead |
|
|
302
|
+
| Method calls (`self.method()`) are conservatively handled | Some valid edges may be missing, but false positives are reduced |
|
|
303
|
+
| Dynamic dispatch is not tracked | Results reflect static structure only |
|
|
304
|
+
| Large full graphs can be hard to read | Use focused views — `trace`, `module`, `reverse` |
|
|
305
|
+
|
|
306
|
+
These are honest limitations, not bugs. Focused views exist precisely because full graphs on real codebases get noisy.
|
|
307
|
+
|
|
308
|
+
---
|
|
309
|
+
|
|
310
|
+
## Roadmap
|
|
311
|
+
|
|
312
|
+
- Better call resolution (method dispatch, aliases)
|
|
313
|
+
- Graph filtering and noise reduction
|
|
314
|
+
- Tree-sitter migration → multi-language support
|
|
315
|
+
- JavaScript / TypeScript support
|
|
316
|
+
- Interactive web UI
|
|
317
|
+
|
|
318
|
+
---
|
|
319
|
+
|
|
320
|
+
## Philosophy
|
|
321
|
+
|
|
322
|
+
**Useful before perfect.**
|
|
323
|
+
CodeMarp v0.1 is not exhaustive. It is correct for common cases and honest about where it isn't.
|
|
324
|
+
|
|
325
|
+
**Readable before complete.**
|
|
326
|
+
A graph you can understand is more valuable than a graph that shows everything.
|
|
327
|
+
|
|
328
|
+
**Static first.**
|
|
329
|
+
No runtime instrumentation. No code execution. Analysis runs anywhere.
|
|
330
|
+
|
|
331
|
+
---
|
|
332
|
+
|
|
333
|
+
## Status
|
|
334
|
+
|
|
335
|
+
- Python only (AST-based, tree-sitter planned)
|
|
336
|
+
- CLI-first
|
|
337
|
+
- v0.1.0 — early but usable on real codebases
|
|
338
|
+
|
|
339
|
+
---
|
|
340
|
+
|
|
341
|
+
## Name
|
|
342
|
+
|
|
343
|
+
**CodeMarp** — sounds like "code map", because that's what it produces.
|
|
344
|
+
|
|
345
|
+
If you want an expansion: *Code Mapping, Architecture, Relationships, and Paths*
|
|
346
|
+
|
|
347
|
+
---
|
|
348
|
+
|
|
349
|
+
*Built to answer the question every developer asks when they open an unfamiliar codebase: where do I even start?*
|