パッケージ管理は名前付けの連鎖である

Package managers are usually described by what they do: resolve dependencies, download code, build artifacts. But if you look at the structure of the system instead of the process, nearly every part of it is a naming problem, and the whole thing works because we’ve agreed on how to interpret strings at each layer and because a registry sits in the middle translating between them.

When you run gem install rails

Companies run private registries with different names for the same packages, or the same names for different packages. Nix, Guix, and Spack layer multiple package repositories with their own namespaces on top of each other. Go uses URL-based module paths where the registry name is literally embedded in the package identity. Which registry you’re talking to determines what every other name in the system means, because a registry name is really a lookup context: give it a package name and it hands back a list of versions.

Some registries insert another naming layer between the registry and the package. Packagist requires vendor prefixes (symfony/console

org.apache.commons:commons-lang3

A namespace is really a claim of authority over a family of names, which makes questions like who gets to publish under @google/

Once you’ve picked a registry and navigated any namespace, you arrive at a package name, and that name resolves to a list of available versions. requests

python-dateutil

Sometimes projects bake a major version into the package name itself, like boto3

Typosquatting exploits the gap between what you meant to type and what the registry resolved; slopsquatting exploits LLM hallucinations of package names that don’t exist yet but could be registered by an attacker. The registry will resolve whatever string you give it, no questions asked.

Pick a version from that list and you get a particular snapshot of code, along with its metadata: a list of dependencies, a list of builds, and whatever the maintainer wrote in the changelog. Versions look like numbers but they’re really strings, which becomes obvious as soon as you see 1.0.0-beta.2+build.456

1.0a1.post2.dev3

When a maintainer account is compromised, publishing 1.2.4

Dependencies and requirements

Each version carries a list of dependencies, and each dependency is itself a pair of names: a package name and a version constraint. requests >= 2.28

The same “convention not enforcement” problem from versioning carries over here. The version constraints are a small language for describing sets of version names, and every ecosystem invented its own. ~> 2.0

Some dependencies are themselves hidden behind yet another name. pip has extras (requests[security]

pip install requests

pip install requests[security]

These constraint languages also compose with the namespace layer. npm’s @types/node@^18.0.0

org.apache.commons:commons-lang3:3.12.0

Builds and platforms

Once the resolver has settled on a version, the client needs to pick the right build artifact, and that means matching platform names. Unlike the earlier naming layers, which are mostly human-coordination problems, platform identity is inherently fuzzy: an M1 Mac running Rosetta is simultaneously two platforms depending on who’s asking, and manylinux

numpy-1.24.0-cp311-cp311-manylinux_2_17_x86_64.whl

nokogiri-1.15.4-x86_64-linux-gnu.gem

If the platform name on the artifact doesn’t match the platform name the client computes for its own environment, the package won’t install, or the wrong binary gets selected silently. And as I wrote about in platform strings, the same M1 Mac is aarch64-apple-darwin

macosx_11_0_arm64

Source repositories

The naming doesn’t stop at the registry. Most packages point back to a source repository, and that’s another stack of names: the host (github.com

Version tags in git are particularly interesting because they’re the bridge between two naming systems. A maintainer creates a git tag called v1.2.3

Naming and trust

At each of these layers you’re trusting that a name resolves to what you think it does, that the registry URL points to the right service, that the package name belongs to who you think it does, that a version was published legitimately, that a constraint won’t pull in something unexpected, that a platform-tagged binary was built from the same source as the one for your colleague’s machine. That trust is transitive, flowing through your dependencies’ names and their dependencies’ names in a chain where nobody has full visibility. The registry is the authority that makes most of these names meaningful, which is why the question of who governs registries keeps coming back to the surface.