1.2.1.2 Dependency Version Differences

Dependency version differences occur when two environments that are meant to run the same application end up with different versions of a library, framework, or runtime installed, often because each environment resolved its dependencies independently and at a different point in time.

How Version Differences Creep In

A project's dependency list might specify a library with a loosely constrained version range, allowing a package manager to install a newer minor or patch release depending on when the install command was run. A machine set up today and a machine set up six months ago can end up with meaningfully different dependency trees even though both followed the exact same installation instructions.

requests>=2.25

A constraint like this permits any version from 2.25 onward, so two installs performed at different times can legitimately resolve to different actual versions.

The Consequences of Drifted Versions

A dependency version difference can change behavior subtly — a default value that changed between versions, a deprecated function that was removed, or a security patch that altered how an edge case is handled — producing a failure in one environment that simply does not occur in another, even though both environments are nominally running "the same" application.

Locking Versions Inside the Image

Docker images, combined with a lockfile that pins exact dependency versions, eliminate this source of difference: once an image is built, the dependency versions inside it are fixed and do not change no matter when or where the image is later run.

FROM node:20-alpine
COPY package.json package-lock.json ./
RUN npm ci

npm ci installs strictly from the lockfile, so the exact versions present at the moment the lockfile was generated are the exact versions present in every container built from this image, indefinitely.

Verifying What Versions Are Actually Present

Rather than trusting that an install step resolved dependencies the same way everywhere, the dependency versions inside a built image can be checked directly.

docker run --rm myapp:1.0 npm list --depth=0
docker run --rm myapp:1.0 pip freeze

Comparing Versions Across Environments

When debugging a failure that appears in only one environment, comparing the dependency versions actually present — rather than assuming they match because the same install instructions were followed — is often the fastest way to find the root cause.

docker run --rm staging-image:latest pip freeze > staging-deps.txt
docker run --rm prod-image:latest pip freeze > prod-deps.txt
diff staging-deps.txt prod-deps.txt