# DEPS — mgf-vm-libvirt's bidirectional dependency manifest

> **§1** — what mgf-vm-libvirt depends on. **§2** — who depends on
> mgf-vm-libvirt. Knowing both directions makes deprecation,
> breaking-change blast-radius, and feature-prioritisation tractable.
>
> **Per standard DOC-16** (v2.12): every project ships a `DEPS.md`.
> Replaces the former `USERS.md`.

Last verified: 2026-06-09.

---

## §1 What mgf-vm-libvirt depends on

| Dependency | Window | Why | Tier |
|---|---|---|---|
| `mgf-common` | `>=0.38,<0.39` | typed exceptions / bootstrap / observability / settings | runtime (sibling) |
| `mgf-vm-core` | `>=0.1,<0.2` | the `HypervisorBackend` + `StorageBackend` contracts this adapter implements + the `mgf.vm.core.conformance` suite | runtime (sibling) |
| `defusedxml` | `>=0.7,<0.8` | hardened domain-XML parsing (XXE / billion-laughs — SH-02 / SH-03) | runtime |
| `libvirt-python` (`python3-libvirt`) | system (apt) | the libvirt / KVM / QEMU binding the adapter wraps | runtime — **NOT a PyPI pin**; ABI-matched to the host `libvirtd`, installed via apt and resolved through `uv venv --system-site-packages` |

*Federation siblings depended on: `mgf-common` (cornerstone — exceptions,
bootstrap, observability) and `mgf-vm-core` (the contracts upstream).*

The runtime PyPI surface is deliberately tight (`defusedxml` only,
beyond the two siblings). The libvirt binding is intentionally absent
from `dependencies` because it must come from the system package to stay
ABI-matched to the installed `libvirt-daemon-system`. Dev/test tooling
(`pytest`, `hypothesis`, `ruff`, `mypy`, `import-linter`) lives behind
the `[dev]` extra.

---

## §2 Who depends on mgf-vm-libvirt

Consumer projects + federation siblings that import `mgf.vm.libvirt`.
(Inverse of each consumer's `MGF_ADOPTION.md`.)

| Project / sibling | Location | Import sites | Status | Surfaces used |
|---|---|---:|---|---|
| **vm-vmanager-agent** (planned) | not yet checked out | 0 | Planned — the per-host kernel that will compose this adapter with the `mgf-hrb` client | `mgf.vm.libvirt.LibvirtAdapter` |

**No downstream consumers yet.** mgf-vm-libvirt is pre-`0.1.0` (Phase 0
of the vm-vmanager-app roadmap); no project imports `mgf.vm.libvirt` today. An
import survey across the sibling checkouts (`mgf-vm`, `mgf-vm-sdk`,
`vm-vmanager-app`) returns zero `mgf.vm.libvirt` import sites — the
existing VM code carries its own self-contained `LibvirtProvider` and has
not yet migrated to this adapter. The planned dependent is
**`vm-vmanager-agent`** (per README §Federation context), which will
compose this adapter via the `mgf-vm-core` contracts to form the
per-host kernel. Update this table in the PR that lands the first import.

---

## §3 Maintenance

Updated every MINOR release + when a dependency or consumer changes.
Import-survey methodology for `mgf.vm.libvirt`:

```sh
for proj in mgf-vm mgf-vm-sdk vm-vmanager-app vm-vmanager-agent; do
  grep -rE "(from|import) +mgf\.vm\.libvirt" "/home/bassam/PycharmProjects/$proj" \
    --include='*.py' | wc -l
done
```
