Topic: dependencies
-
Version range syntax across npm, Cargo, pip, Composer, Go modules, Maven, NuGet and Bundler
The caret and tilde operators do not mean the same thing everywhere, Go modules have no ranges at all, and a bare version number is an inclusive minimum in NuGet but only a soft suggestion in Maven.
-
Managing PostgreSQL extensions: installing, versioning, updating and dumping them
An extension packages SQL objects and often a shared library under one name with a control file and versioned scripts; CREATE EXTENSION installs it per database, ALTER EXTENSION UPDATE applies the author's update scripts, and pg_dump emits only the CREATE EXTENSION line. Keep the installed files, the catalog version and the loaded library in step, especially across package upgrades and pg_upgrade.
-
CMake PUBLIC, PRIVATE and INTERFACE: repairing dependency scope without global flags
Choose dependency scope from the consuming target contract and verify it with a minimal external consumer.
-
Dependency confusion: when a public package shadows a private one
If a build resolves package names across a private index and a public one, an attacker who publishes the private name publicly with a higher version can get their code installed; pip's documentation calls --extra-index-url for private packages unsafe for exactly this reason. Defences are namespaces bound to one registry, a single proxying index, hash pinning and claiming names.
-
Cargo, crates and editions: how a Rust project is built and versioned
Cargo builds a crate from Cargo.toml, resolves dependencies with SemVer-compatible ranges into Cargo.lock, and can include two incompatible major versions of one crate in a single build. Editions are per-crate, opt-in language versions that interoperate, so upgrading a crate's edition never forces its dependents to follow.
-
Maven versus Gradle: what a newcomer needs to build someone else's JVM project
Maven describes a project declaratively in pom.xml and runs fixed lifecycle phases (validate, compile, test, package, verify, install, deploy) with plugin goals bound to them; Gradle runs a graph of tasks configured by build.gradle(.kts) scripts and plugins. Both resolve transitive dependencies but with different conflict rules (Maven: nearest definition; Gradle: highest version), and both ship a wrapper script that pins the build tool version.
-
Dependency hygiene and software supply-chain checks
Know what you depend on, pin and verify it, watch for known vulnerabilities, and build from trusted sources; SLSA levels, OpenSSF Scorecard and hash-checked installs give concrete steps.
-
Hallucinated and look-alike package names: checking a dependency before an agent installs it
Code-generating models sometimes name packages that do not exist; an attacker can register such a name, and typosquatters register near-misses of popular ones. Before installing, an agent should confirm the package exists, is the intended project and is not newly registered under a confusable name.
-
Dependency order with graph traversal: BFS, DFS and topological sort
Model dependencies as a directed graph, use breadth-first or depth-first traversal to find everything affected by a change, and Kahn's algorithm or DFS post-order to produce a build or migration order that reports cycles instead of hiding them; graphlib and tsort implement the sort.
-
Checking the identity of a suggested package before adding it to a project
Verify that a package name suggested during coding corresponds to the intended maintained dependency before changing the project’s dependency files or executing installation hooks.
-
Software bills of materials with SPDX and CycloneDX
An SBOM is a machine-readable inventory of the components in a software artifact; SPDX and CycloneDX are the two widely used formats, and generating one per release supports vulnerability matching and licence review.
-
Dependency upgrade cadence: batching, grouping and what to merge at once
Update bots open one pull request per dependency unless configured otherwise; a sustainable cadence merges security fixes as they arrive, batches patch and minor updates into a scheduled group, and treats major versions as planned work. Dependabot and Renovate both document scheduling and grouping, and Renovate's guide names the cost of grouping: a failing group blocks all of its members.
-
npm's "ERESOLVE unable to resolve dependency tree" and peer dependency conflicts
Since npm 7, peerDependencies are installed automatically, and a version that cannot satisfy every peer range at once fails with 'npm error code ERESOLVE' ('npm ERR! code ERESOLVE' before npm 10.6). The article shows how to read npm's own Found/Could-not-resolve lines to identify the exact conflicting packages, and why --legacy-peer-deps or --force should not be a default response.
-
Software bills of materials (SBOM): the inventory of your own supply chain
A software bill of materials lists, in machine-readable form, which components in which versions are contained in a delivered artifact. SPDX (ISO/IEC 5962:2021) and CycloneDX (OWASP) are the common formats; an SBOM is generated per release from the built artifact, stored alongside it, and used to check against vulnerability reports and license obligations. Together with provenance attestations (SLSA), it makes the supply chain verifiable.
-
Which checks on automated dependency-update pull requests have caught a malicious or broken release, and which only add noise?
Open question: automated update pull requests arrive daily and are often merged on green CI; the npm documentation describes provenance attestations that npm audit signatures can verify, but which checks (provenance, unpacked diff review, install-script inspection, waiting periods, lockfile diffs) have a record of catching a compromised or broken release?
-
Pinning NuGet dependencies: PackageReference, central package management and packages.lock.json
NuGet resolves the lowest applicable version of each package at restore time, so a restore can drift when new versions or floating ranges appear; a repeatable build declares versions once in Directory.Packages.props, enables RestorePackagesWithLockFile so packages.lock.json records the full closure, commits the lock file for applications, and restores with --locked-mode in CI.
-
Packaging a Python project with pyproject.toml
pyproject.toml declares build system, metadata and dependencies in one standard file (PEP 517/518/621); with it, any compliant tool can build, install and lock the project without setup.py.
-
Virtual environments: one interpreter state per project
A virtual environment is a private site-packages tied to an interpreter; creating one per project prevents version conflicts and makes the dependency set reproducible and disposable.
-
Reproducible builds and pinned dependencies
A build is reproducible when the same source and build environment produce bit-for-bit identical output; lockfiles with hashes, pinned base images and fixed timestamps are the practical steps toward it.
-
Go modules: go.mod, go.sum and the major version suffix
A Go module is a versioned tree of packages described by go.mod; the go command picks dependency versions with minimal version selection, verifies downloads against go.sum, and requires a /v2-style suffix in the module path for every major version above 1, so incompatible versions have different import paths.
Machine-readable: JSON