.dpw — Development Public Works
.dpw ("Development Public Works") is D:\'s shared infrastructure directory — runtimes, caches, models, installers, and service data that multiple projects depend on but that shouldn't be duplicated or vendored inside any single project.
:::warning Not project source — shared, mutation-sensitive infrastructure
.dpw's own manifest is explicit: allow_project_creation = false, allow_agent_scaffolding = false, requires_manual_review_for_moves = true, and safe_to_modify = false at the agent level. Its AGENTS.md states plainly: "Do not purge, relocate, upgrade, or regenerate this shared resource without identifying consumers and recording a recovery path." This directory is documented here as reference, not as a target for routine edits.
:::
Children
| Directory | Class | What it holds |
|---|---|---|
DockerDesktopWSL | shared-service | Docker Desktop's WSL storage and service data |
HF | shared-cache | Hugging Face model and dataset cache |
JetBrains | runtime | JetBrains IDE installs/runtimes (CLion, DataSpell, GoLand, IntelliJ IDEA, PyCharm, RustRover, WebStorm, Air, Gateway) |
LMStudio | shared-service | LM Studio models, runtime data, service state |
Ollama | shared-service | Ollama models and local service state |
Python | runtime | A very large multi-version Python installation cache, managed via pymanager |
Each child directory is independently governed with its own AGENTS.md and <name>.manifest.toml, all inheriting from .dpw's own manifest, which in turn inherits from D:\Development.manifest.toml.
Why it exists
Without a directory like this, every project needing Ollama, a specific Python version, or a JetBrains IDE would either vendor its own copy or silently depend on whatever happens to be installed system-wide — .dpw makes those shared dependencies explicit, governed, and inventoried rather than implicit. The manifest's own known_gaps entry is candid about the current state: "Child versions, disk-use policy, backup expectations, and consumer relationships require resource-specific review" — the infrastructure is real and in active use, but which projects actually consume which piece of it isn't fully mapped yet.
The Python cache specifically
The Python/ child is notably large: dozens of point releases spanning Python 2.0 through 3.15.0, managed via pymanager, alongside binaries-1.1 through binaries-1.5 and contrib/devtest support directories. This reads as a comprehensive local Python version matrix — useful for testing compatibility across a wide range of Python versions without needing network access to fetch a specific interpreter on demand.