Review Python dependency resolution before an agent installs anything

Review selection before file admission

An agent proposes one Python dependency for a report worker. Even if its top-level version is fixed, the review still needs to explain which source supplies it, which dependencies are selected, which target environment those files fit and whether a source build would add another execution path.

This differs from checking an already selected model artifact's digest: the question is how the candidate set was chosen. This guide uses fictional package, index, artifact and target labels only. Every decision and check is PROPOSED_UNRUN. No pip command, registry query, resolution, download, metadata build, installation or package import was performed.

Record effective configuration and target context

The actual primary documentation inspected here identifies itself as pip 26.2.2; no installed pip version was inspected. Its configuration guide describes command-line settings overriding environment variables, which override configuration-file values, with further file and section precedence. A checked-in configuration file alone therefore does not establish effective behavior.

For a future authorized workflow, retain a sanitized configuration snapshot: resolver version, interpreter version/implementation, ABI, target platform, marker/extras inputs, existing-environment assumptions, requirements or lock format/revision, source locations and relevant binary/build/hash policy. Identify the source of each effective setting without copying credentials or private paths into a shared report.

The install reference documents separate target compatibility options. Record intended target settings as well as the environment that produced any evidence. Do not assume that a report created on one worker establishes another worker's compatibility.

Inspect the source and dependency graph together

The install reference states that searched locations have no priority: pip considers configured indexes, additional locations and applicable local sources, selecting a matching candidate under its rules. Adding an extra index is not a promise that a preferred index wins first. Source authorization needs an explicit policy separate from version compatibility.

Pip's resolution guide explains backtracking between compatible dependency choices. A top-level pin does not by itself document the selected transitive graph. Review the resulting nodes and edges against the approved baseline and target, rather than accepting a list of requested names as the complete environment.

For the invented worker, P-A version 1 depends on P-B in range 2–3, excluding 3. P-B version 2.4 adds P-C version 4.1 under fictional marker M-A. Target T-A stands for a separately recorded interpreter/ABI/platform/marker snapshot. These labels are not real requirements or a pip report.

Baseline R-1, target T-A:
  P-A@1   -> [email protected] -> [email protected] under M-A
  allowed source: I-A
  expected artifacts: W-A, W-B, W-C
  digest references: H-A, H-B, H-C
  source builds: not permitted by this fictional plan

H-A through H-C are symbolic references, not calculated hashes. A real baseline would need independently established source trust and exact artifact digests.

Use a selection-change decision matrix

These are application review rules, not observations about a registry. Unknown provenance does not establish maliciousness; it establishes an unresolved admission decision. Keep a permitted complete counterpart so an always-reject process cannot be mistaken for a useful workflow.

Keep builds and hash enforcement explicit

The build-system documentation describes build environments, build dependencies and metadata-generation hooks. A source-distribution path can therefore require more than inspecting an archive name. Build isolation separates build dependencies from the runtime environment; it is not a blanket authorization to execute an unreviewed backend.

The secure-installs guide describes complete hash-checking requirements, including dependencies. It also documents the --no-require-hashes opt-out added in 26.2 that disables automatic all-requirements enforcement. Check the effective mode, not merely the presence of one hash. Matching approved bytes still does not establish harmless code or authentic origin if the baseline itself is untrusted.

If a separately authorized later stage obtains dependency metadata, its network and build behavior needs explicit scope. Nothing here generates a report or assumes that a “would install” operation is an operation-free inspection.

Respect report and origin-record limits

The installation-report reference defines versioned records including producer version, environment, artifact download information and requested-versus-dependency status. It explicitly says the report is not a lock-file format and is not accepted as installation input. Preserve the exact requirements or lock artifact separately; do not relabel a JSON report as an enforced environment.

PyPA's installed Direct URL origin specification requires direct_url.json for direct-reference installs, not ordinary name/version installs. Its absence is not proof that an index artifact lacks an origin. The data-structure specification describes archive/VCS/directory information and removing sensitive authentication information from persisted URLs. These records describe origin information; they do not independently authenticate a producer.

Boundary's planned request router is not a Python resolver or package-admission service. Its eight mock policy checks are separate evidence. A future review should name the exact configuration, graph, artifacts, unresolved gaps and authorized next stage; this worksheet establishes no installation or security result.