Dependency management is the process of declaring, selecting, recording and maintaining the external software a project needs. For a quant application, that includes the libraries behind data handling, numerical routines and reporting. A pricing script can stay unchanged while a library upgrade changes its behaviour; managing dependencies makes that change visible and reviewable.
Direct dependencies lead to more dependencies
A direct dependency is one the application explicitly requires. A transitive dependency is required through another dependency. In the fictional graph below, the risk application requires
pricing-core, which in turn requires numerics-lib. The application therefore relies on both, even if its own source never imports numerics-lib.
Fictional dependency graph and version constraint. Arrows point from a package to software it requires; an allowed version is only a candidate for the full environment.
A Python requirement such as
pricing-core>=1.2,<2.0 permits version 1.4 and excludes 2.0. Both bounds apply together. This is a compatibility claim declared by the project, rather than evidence that every permitted release has passed its pricing tests. Release labels are versions, not decimal numbers: 1.10 follows 1.4.Dependency resolution selects versions that jointly satisfy the applicable requirements. The resolver must consider requirements further down the graph, along with interpreter and platform restrictions. Satisfying the application's range alone does not establish that a complete compatible selection exists. If two packages require incompatible versions of the same dependency, a resolver may reject the combination. Pip's resolution documentation explains this search and its backtracking.
A range and an exact record answer different questions
| Record | Question it answers | Limit |
|---|---|---|
| Declared requirements | Which dependencies and versions may this project use? | A range can admit different selections on different dates. |
| Resolved dependency record | Which direct and transitive versions and artifacts were selected for a target environment? | Its scope and platform support depend on the recording tool and format. |
| Validated run record | Which code, environment, configuration and data produced this result? | It still needs a successful replay and appropriate numerical checks. |
Package pinning fixes a dependency to a particular version, for example
pricing-core==1.4. Pinning only direct dependencies leaves room for transitive packages to change. For repeatable installation, record the full selected set and, where supported, artifact hashes and sources. A hash verifies the retrieved artifact's identity; it does not establish that its code is correct. Pip documents these progressively stronger records in Repeatable Installs.An installed-package inventory also needs careful interpretation.
pip freeze reports installed packages in requirements format; it does not perform resolution or compute a lockfile. A cluttered research environment may contain packages unrelated to the application. Keep the project's declared needs distinct from an inventory of one machine. This distinction follows the current pip freeze documentation.Keeping a valuation rerunnable
A virtual environment separates a project's Python packages from other projects. Isolation helps control changes, but it does not itself choose versions or preserve a previous installation.
For a result that must survive review, retain the dependency record alongside the interpreter version and relevant operating-system or native-library details. Also retain the code revision, configuration, random seed when applicable, and market-data snapshot. Dependency management supplies part of a reproducible environment; it cannot recover yesterday's closing prices from a live data feed.
Treat an upgrade as a model-delivery change: review the dependency changes, rebuild in an isolated environment and rerun the relevant tests. A resolver checks declared software compatibility. Tests and model review examine whether the resulting application still behaves as intended.
For an owned worked continuation, Packaging a Quantitative Model connects package metadata, imports and numerical tests. Reproducibility extends the dependency record into a replayable research run. Both offer public previews; the full lessons require membership.
Sources
- Python Packaging Authority, Dependency specifiers — package requirements, combined version constraints and environment markers.
- Python Packaging Authority, Version specifiers — numeric release-segment ordering.
- Python, venv — environment isolation and its limits.
- Pip, Dependency Resolution — compatible selections, transitive requirements and backtracking.
- Pip, Repeatable Installs — exact versions, hashes and platform-specific installation artifacts.
- Pip, pip freeze — the distinction between an installed inventory and a lockfile. Pip pages consulted in documentation version 26.2.2 on 28 October 2026; no package installation is required by this article.