A conda explicit spec file is a plain text list of exact package URLs, one per line, under an @EXPLICIT header. You can add MD5 or SHA256 hashes to each URL. It pins the exact build of every conda package, so a rebuild fetches the same files instead of re-solving.
Definition
The conda documentation describes explicit spec files as a way to build an identical environment on the same operating system platform. They skip the solver, because every package is already named. The header comment shows the command that consumes the file, which is conda create with the file option.
Compare that with an environment.yml, which records names and loose version constraints. Two people running conda env create from the same environment.yml a month apart can get different results. An explicit file removes that gap.
How to produce one
Run these commands inside the environment you want to capture:
conda list --explicit --sha256 > spec-linux-64.txt
conda create --name rebuilt --file spec-linux-64.txt
The conda list reference documents the explicit option together with an option for MD5 and one for SHA256, and notes that authentication details are removed from URLs by default. Name the file after its platform, because the file is platform specific.
What it pins and what it skips
| Question | Explicit spec file | environment.yml |
|---|---|---|
| Exact package builds | Yes | No |
| Hash of each archive | Optional, if you ask for it | No |
| Works across operating systems | No, one file per platform | Mostly, with loose pins |
| Includes pip packages | Not as a lock | Yes, in a pip section |
| Human readable intent | Weak | Strong |
The last two rows matter. The documentation notes a pip installed package is invisible to conda's own bookkeeping, so do not assume the explicit file captures your pip layer. Record that separately, for example with hashed requirements.
When hashes help
A hash lets an installer detect that a downloaded archive differs from the one you recorded. That is useful if a channel is tampered with or a package is replaced under the same name and version. It does not tell you the original package was safe. A hash proves sameness, not goodness.
A practical routine
- Keep environment.yml as the human edited source of intent.
- Generate an explicit spec with hashes for each platform you deploy to, in CI.
- Commit the explicit files, and review their diffs like any dependency change.
- Scan the explicit file contents for known vulnerabilities on a schedule, since a pinned package stays vulnerable until you change it.
The dependency inventory view shows what such a list looks like once it becomes a tracked inventory.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each package carries an exact version, since that is the data an explicit spec gives you.
Safeguard's SBOM and dependency scanning can turn a pinned list into a living inventory. Check which lock formats it reads for your ecosystem, or run the free scan at gold.safeguard.sh/scan.
Quick check
Is an explicit spec file portable between Linux and macOS?
No. The documentation describes it for the same operating system platform. Keep one file per platform.
Does a SHA256 in the file make the package safe?
No. It only proves the archive matches what you recorded earlier.
Sources
- Managing environments, conda documentation, fetched 19 October 2026.
- conda list, conda documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
