mops install

Install all dependencies specified in mops.toml

mops install

Lockfile behavior

The lockfile is considered up to date when the [dependencies] and [dev-dependencies] in mops.toml haven't changed since the lockfile was last written.

• Lockfile up to date — installs the exact versions recorded in the lockfile, skipping dependency resolution.
• Lockfile missing or out of date — runs full dependency resolution, installs resolved versions, then creates/updates the lockfile.

mops install is self-healing: a missing, unparseable, legacy-format or mops.toml-inconsistent lockfile is regenerated rather than treated as an error. There is no flag to opt out of the lockfile — it is always maintained.

See mops.lock for details on lockfile contents and when to commit it.

Version conflicts

When dependency resolution runs, mops install reports any registry dependency that two packages in the graph request at different major versions:

Warning! Conflicting major versions of dependency "test"
  test 1.2.0 is a dependency of legacy@1.0.0
  test 2.1.2 is a dependency of my-app@1.0.0
  Resolved to test 2.1.2 — dependents on another major compile against an API they did not ask for.
  If you want a different version, pin it in your root mops.toml — a root dependency always wins.

Resolution still succeeds: the highest major wins, unless your own mops.toml pins the dependency, in which case yours wins. Packages differing only in minor or patch version are not conflicts and are not reported. Neither are repo or path dependencies, which carry no comparable major version.

Since resolution is skipped when the lockfile is up to date, the report appears on the run that creates or updates mops.lock. If you have reviewed a conflict and decided to keep it, mops sources --conflicts ignore silences it there.

Options

--locked

Require an up-to-date lockfile and never write it. This is the flag for CI.

mops install --locked fails when:

• mops.lock is missing
• mops.lock cannot be parsed, or is not the current format version
• mops.toml declares dependencies that mops.lock does not pin to the same values
• a file hash in mops.lock does not match the Mops registry

On success, mops.lock is left byte-for-byte untouched.

--locked is also available on every command that installs dependencies implicitly — mops build, mops check, mops check-candid, mops check-stable, mops test, mops bench and mops generate candid — so a CI job can run mops test --locked without a preceding install step.

mops install --locked   # CI: fail rather than update the lockfile
mops install            # dev: keep the lockfile in sync

mops sources deliberately has no --locked: it is invoked as a packtool in the middle of another tool's build, and its stdout is machine-parsed. Enforce the lockfile with a preceding mops install --locked step instead.

--no-toolchain

Do not install toolchain.

--verbose

Verbose output.

CI

Pass --locked explicitly and commit mops.lock:

- run: mops install --locked
- run: mops test --locked

The CI environment variable no longer changes lockfile behavior. Earlier releases silently switched mops install to check mode when CI was set (deprecated since 2.18); that auto-detection was removed in 3.0.

Verifying installed files

mops install verifies each downloaded file against the registry's published hash as it arrives, before it is committed to the cache — so a corrupted or tampered download never reaches your project. It does not re-hash the contents of .mops/ on every run.

To audit what is currently on disk, run mops verify.