One File - What if your lockfile and your package list were the same file?

Summary

Every package manager I’ve used draws a line between what you ask for and what you get.npm has package.json and package-lock.json. Cargo has Cargo.toml and Cargo.lock. Nix has flake.nix and flake.lock. The pattern is universal: one file for intent, another for resolution. You write the first. The tool writes the second. They’re different formats with different rules, and you need both to reproduce a build.This split exists for good reasons. Intent is loose — “give me vim” — and resolution is precise — “give me vim 9.1.0, release 1, with this exact content hash.” Those feel like different things, so they get different files.When I was designing the package manager for Mere, I kept coming back to a question: do they actually need to be different?The gradient#In Mere, a profile is described by a profile.kdl file. Here’s the simplest possible one:profile { package "make" } That’s a statement of intent: I want make. When you apply this to a profile, Mere resolves it — finds the latest version, fetches it, installs it to the content-addressed store, and writes a realized profile:profile { schema-version 2 created-at 1774407107 profile-name "lyra-test" package "make" version="4.4.1" release=3 \ content-hash="9426fcd11c446be26544b763d6d649186ec9fd98142204a79d582dc6409ecead" } That output is the resolution. It records exactly what was installed, down to the content hash of the package in the store.Here’s the thing: that output is also valid input.Feed it back into mere profile apply on another machine, and you get the exact same package. The content hash drives the lookup — Mere checks the local store first, fetches by hash if it’s missing. No resolver needed. No ambiguity.There’s no separate lockfile because the resolved form is the same format as the input. The tool reads both equally. What changes is precision:Name only → “give me the latest”Name + version → “pin to this version”Name + version + content hash → “reproduce exactly this”Users never need to write a content ha...