// the find
hoangsonww/ReproVM-Virtual-Machine
⚙️ A lightweight C-based task VM with content-addressed storage, automatic incremental caching, and terminal-visible dependency graphs; parallel-capable, polyglot (Go, Rust, Python, Node.js, Ruby, assembly) workflow engine with Docker support for reproducible pipelines.
ReproVM is a small C99 task runner that hashes a command plus its input file hashes and upstream results to decide whether to re-run or restore from a content-addressed cache, printing a live ASCII dependency graph as it goes. It's aimed at someone who wants Bazel/Nix-style incremental caching for a shell-based build or data pipeline without pulling in an actual build system.
The core idea is done correctly: task hash = cmd + sorted input blob hashes + dependency result hashes, so invalidation propagates transitively through the DAG exactly like a real build system's action graph, in well under a thousand lines of C. CAS objects are sharded into two-level hex directories, the standard fix for directory-entry blowup. The optional pthread executor respects the DAG while leaving the serial code path untouched, which is a sane way to add concurrency without risking the simple case.
Task commands run through system() with no sandboxing, and the README itself flags this under 'Security Considerations' — pointing it at an untrusted manifest is arbitrary shell execution. The repo has sprawled well past 'lightweight': audit, backup, compression, health-check, metrics, notifications, prometheus, rate-limiter, remote-CAS, and systemd unit files sit alongside the core VM with no evidence in the tree that they're actually wired into task execution. Documentation is a wall of badges plus four overlapping files (ADVANCED_FEATURES, COMPLETE_FEATURES_SUMMARY, ENHANCEMENTS_SUMMARY, PRODUCTION) that read like padding rather than one clear doc. Cache integrity relies on hash existence alone — a swapped CAS blob is trusted silently, which the README admits but doesn't fix.