BUG: erlang is unstable in lockfile - gets re-generated all the time and causing churn

[dkarter]

This is happening to multiple people on our team and has become more of an issue since lockfiles became on by default.

We check the lock file in and between installs the erlang entry gets removed then on other installs re-added - this is seems to be a long standing bug.

diff --git a/mise.lock b/mise.lock
index 53c1113ea0..fa4a4bc3c7 100644
--- a/mise.lock
+++ b/mise.lock
@@ -208,22 +208,6 @@ checksum = "sha256:9f030b550cf79d4564a1dc697f015b4d7b463261df1bcc61314b1a28367f8
 url = "https://github.com/erlef/otp_builds/releases/download/OTP-29.0/otp-x86_64-apple-darwin.tar.gz"
 url_api = "https://api.github.com/repos/erlef/otp_builds/releases/assets/419152404"

-[[tools.erlang]]
-version = "29.0"
-backend = "core:erlang"
-specifiers = ["29.0"]
-
-[tools.erlang.options]
-precompiled_os = "ubuntu-24.04"
-
-[tools.erlang."platforms.linux-arm64"]
-checksum = "sha256:49e57d55e25d1e8c98e0b7f633018b7d8f196a0eed302dd744c27ac467f7bc7b"
-url = "https://builds.hex.pm/builds/otp/arm64/ubuntu-24.04/OTP-29.0.tar.gz"
-
-[tools.erlang."platforms.linux-x64"]
-checksum = "sha256:6b845ac4a9ef522b2291f37bf121ccb584bf9da4b8a143491cf7a58814b51d6d"
-url = "https://builds.hex.pm/builds/otp/amd64/ubuntu-24.04/OTP-29.0.tar.gz"
-
 [[tools."github:chmln/sd"]]
 version = "1.1.0"
 backend = "github:chmln/sd"

mise.toml

[tools]
erlang = "29.0"

[settings]
lockfile_platforms = ["linux-x64", "linux-arm64", "macos-x64", "macos-arm64"]

[jdx]

There are two separate defaults here: existing lockfiles are read and updated by default, but automatic creation of a new lockfile requires lockfile = true in the configuration (or an explicit mise lock).

The Erlang churn is a separate issue. Its Linux precompiled build and macOS source build have different option variants. The incremental install writer can drop the other platform's variant, which a subsequent lock operation recreates.

I've opened #13031 with a broader, opt-in generator. It rebuilds the selected lockfile scope from current requests while reusing unchanged artifact metadata, rather than incrementally merging host installation results. It also retires provenance_verified as a trust flag, preserving existing values as inert compatibility metadata.

Once you have a build containing that PR, could you try this in mise.toml?

[settings]
lockfile_mode = "generate"

Run mise lock once, then use your normal install workflow on macOS and Linux. This setting doesn't change automatic-creation eligibility or require a format migration. Return to lockfile_mode = "merge" to opt out.

The first run may download artifacts for other platforms to hash and verify them. During installation, that work overlaps installation and has a dedicated lock progress bar; unchanged entries should be reused afterward.

Does generation stop the Erlang lockfile churn for your team? How do first-run and subsequent-install performance feel?

merge remains the initial default. The first December release has a maintainer decision gate to review trial feedback and either promote generation or explicitly postpone it—not a wall-clock switch.

AI-assisted — Tool: Codex; model: OpenAI/unavailable; version: unavailable.

[dkarter]

Thank you!

I tried it and it indeed solves the issue, but def made performance somewhat worse:

warm installs average in generate mode (for three platforms linux-x64, linux-arm64, and macos-arm64) 451.1 ms ± 15.4 ms, versus 322.3 ms ± 3.8 ms in merge mode: about 129 ms or 40% slower (at the high end)

[jdx]

@dkarter thanks for testing and sharing the timings. Some extra work is expected because generate rebuilds the lockfile across the configured platforms, even when the artifact metadata is cached. But there is room to improve warm runs.

I've opened #13101 to avoid spawning work for fully cached entries and skip no-op provenance checks, while preserving the existing verification and downgrade protections. A synthetic debug-build benchmark with 30 cached tools across three platforms went from 2.99 ms to 2.42 ms for the generation loop. That is a small absolute saving, not a 19% improvement to the full install command, and it doesn't account for the full 129 ms you're seeing.

Once you have a build containing that PR, could you rerun the same benchmark? Your project would be a useful check of the end-to-end impact.

AI-assisted — Tool: Codex; model: OpenAI/unavailable; version: unavailable.

[jdx]

@dkarter a follow-up: I looked further, and a fully warm install should be able to skip rebuilding an already-current lockfile. I've opened #13103 to do that after checking that the resolved tools, options, and platform metadata still match. Verification and concurrent-edit protections remain in place.

In a synthetic project with 30 installed tools across three platforms, the full warm install went from 83.9 ms to 74.2 ms, versus 65.7 ms for merge (debug builds). That's roughly half of the remaining extra generation cost removed in this fixture. Configuration resolution and validation still run, so it isn't literally a no-op. These numbers don't establish how much of your 129 ms difference this will recover.

Once a build containing this PR is available, could you rerun your same benchmark? That would help establish the impact on your project.

AI-assisted — Tool: Codex; model: OpenAI/unavailable; version: unavailable.