Glossary¶
- Archive¶
A compressed file (
tar.gz,tgz,tar.bz2,tar.xz, orzip) served over HTTP, HTTPS, or afile://URL used as a dependency source. Declare it withvcs: archivein the manifest. Unlike Git or SVN projects, archives carry no VCS history; use the Integrity field to verify the download cryptographically.- Destination¶
The local path, relative to the manifest file, where Dfetch places the fetched files of a subproject. Set with the
dst:attribute; defaults to the projectname:when omitted.- Freeze¶
The operation performed by
dfetch freezethat replaces every loosebranch:or opentag:reference in the manifest with the exact revision that is currently fetched. Produces a fully reproducible manifest where every dependency is pinned to a specific commit or archive URL.- Integrity¶
An optional cryptographic hash declared in the manifest under
integrity.hash:for Archive dependencies. Format is<algorithm>:<hex-digest>(e.g.sha256:e3b0c4…). Dfetch verifies the downloaded archive against this hash before extracting it, and records it in the generated SBOM.- Manifest¶
The
dfetch.yamlfile that describes all dependencies of a Superproject. It lists Remote sources and the Subproject entries to fetch, together with their version pins, source paths, and patches. Dfetch searches upward from the current directory to locate the manifest automatically.- Metadata¶
The
.dfetch_data.yamlfile that Dfetch writes inside each fetched Subproject directory. It records the URL, VCS type, and exact revision that is currently present, allowing Dfetch to detect out-of-date or locally modified dependencies without re-contacting the remote.- Patch¶
A
.patchfile that captures local modifications to a vendored Subproject. Declared with thepatch:attribute in the manifest, patches are automatically re-applied bydfetch updateafter each upstream fetch. Created withdfetch diffand reformatted for upstream submission withdfetch format-patch.- Remote¶
A named entry in the manifest that provides a common
url-basefor multiple projects. Instead of repeating a full URL for every Subproject, projects can reference the remote by name and supply only theirrepo-path:.- Repo-path¶
The path appended to a Remote’s
url-baseto form the full repository URL of a Subproject. Use it together with aremote:reference to avoid repeating the URL base across many entries.- SBOM¶
Software Bill of Materials. A machine-readable inventory of all vendored dependencies, generated by
dfetch report -t sbom. Dfetch produces SBOMs in CycloneDX JSON format, including each dependency’s URL, revision, auto-detected license, and — for Archive sources — a cryptographic hash when an Integrity field is present.- Source¶
The subfolder inside an upstream repository to copy, declared with the
src:attribute. Only the files under that path are placed in the Destination; the rest of the upstream repository is ignored. License files are always retained regardless of thesrc:setting.- Sub-manifest¶
A
dfetch.yamlfound inside a fetched Subproject. After fetching, Dfetch inspects sub-manifests and reports any further dependencies they declare, so you can decide whether to vendor those transitively. Pass--no-recommendationstodfetch updateto skip this check.- Subproject¶
A dependency declared in the Manifest that Dfetch copies into the Superproject. A subproject can be sourced from a Git repository, an SVN repository, or a plain Archive URL.
- Superproject¶
The top-level project that owns the Manifest. It coordinates all Subproject dependencies and is typically the repository that is committed to version control.
- Vendoring¶
The practice of copying third-party source code directly into your own repository rather than relying on a package manager to fetch it at build time. Dfetch automates the fetch, version-pinning, patching, and update lifecycle of vendored dependencies. See Vendoring for a detailed discussion of the trade-offs.