---
name: Dependency
type: relationship/structural
status: running
version: 4.2.1
released: "~3.8 billion BCE"
maintainer: entropy
dependencies:
  - existence
  - scarcity
  - time
license: Unavoidable Commons v1.0
tags:
  - architecture, coupling, reliance, graphs, vulnerability, love, infrastructure
---

Dependency

What it actually is

A formal admission that you cannot do this alone.

How it works

One node in a graph requires output from another node before it can produce its own. The dependent node blocks. The dependency either resolves, times out, or fails silently, poisoning everything downstream.

This pattern appears identically in:

package managers
ecosystems
attachment theory
supply chains
neurons
marriages

The mechanism does not care which domain it is running in.

Features

Transitive closure: your dependencies have dependencies. It goes all the way down. There is no bedrock node.
Version pinning: some relationships lock to a specific version of a person or system and refuse to upgrade. Common. Costly.
Circular dependency: A needs B, B needs A. Both block. Both call this love under certain conditions.
Optional dependency: listed, rarely invoked, missed enormously when removed.
Dev dependency: only needed during construction. In theory, not shipped to production. In practice, always shipped to production.

Known bugs

dependency_not_found: the thing you were built around no longer exists. Cascading failure likely.
version_mismatch: the version of someone you depend on has changed. Your expectations have not.
undeclared_dependency: you discover at runtime that you needed something you never listed. Common with childhood environments. Very hard to debug retroactively.
star_dependency (*): accepts any version of the dependency. Appears flexible. Is actually just unexamined.

Configuration

dependency:
  type: hard          # hard | soft | optional | circular
  pin_version: false  # true = growth blocked for both parties
  fail_behavior: cascade  # cascade | isolate | silent
  acknowledge: false  # most users leave this at false
  direction: mutual   # mutual | one-way | delusional

Note: Setting acknowledge: false does not remove the dependency. It relocates it to denial.

Error codes

Code	Message	Common Cause
`DEP_001`	Cannot resolve module	The thing left
`DEP_002`	Circular reference detected	Two people mid-negotiation
`DEP_003`	Deprecated API still in use	Nostalgia as architecture
`DEP_004`	Peer dependency conflict	You have changed; they have not
`DEP_005`	Install failed silently	grief with no apparent trigger

Edge cases

A dependency can be so deeply embedded it is no longer visible in the manifest. This is sometimes called infrastructure and sometimes called a parent.
Removing a dependency you did not know you had is indistinguishable from a random crash. Treat accordingly: with patience, with logging, with time.
Some nodes become stable only after accepting a hard dependency. The refusal to declare one is itself a configuration choice with known performance costs.

FAQ

Is all dependency bad? No. A node with zero dependencies produces nothing and receives nothing. This is called isolation and is not the goal.

Can I mock my dependencies? In testing, yes. In life, you can try. The mock will eventually fail to match the real interface.

What is the difference between a dependency and a habit? Compile time versus runtime. Sometimes.

drafting spec…