The SDK's delivery is decided; the git URL violates it
ADR 0014 is accepted and unambiguous: each module consumes its dependencies from the private registry, the mesh's own shared library included, and a cross-package change is publish then consume. So the git dependency at a pinned commit is not a mechanism under consideration. It is the shared library being consumed a way the record rules out, and the lock naming a sibling directory is what that looks like when nobody publishes. Issue 053 is reclassified from a question about mechanism to a violation with a direction. What stays open is narrower and real: which software serves the private registry, and that a fresh mesh has none when the first SDK is built — ADR 0014 assumes one exists, and at genesis nothing has installed it. Recorded after arguing at length for a bespoke content-addressed alternative, against a decision that was already made and that I had not read. Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx
This commit is contained in:
@@ -163,9 +163,13 @@ knows. Putting the Plex client anywhere else is the shared-library disease with
|
||||
|
||||
### What this leaves open
|
||||
|
||||
- **Which registry.** The catalogue holds a `verdaccio` module, and a forge typically serves package
|
||||
registries too. Two answers exist and nothing says which is the mesh's. That has to be settled
|
||||
before anything publishes.
|
||||
- **Which private registry.** That there *is* one is settled —
|
||||
[ADR 0014](../../02-DECISIONS/0014-no-npm-workspace.md) says each module consumes its dependencies
|
||||
from the private registry, the mesh's own shared library included. Which software serves it is
|
||||
not: the catalogue holds `verdaccio`, and a git host usually serves package registries too.
|
||||
- **And the bootstrap does not have one.** ADR 0014 assumes a registry exists; on a fresh mesh
|
||||
nothing has installed one when the first SDK is built. That is the same pivot as everything else
|
||||
and it has not been designed.
|
||||
- **Who may publish.** A builder pushing a package needs an account on that registry, which is a
|
||||
credential in the bootstrap path and does not exist yet.
|
||||
- **Versions and ranges.** Everything else the mesh delivers is pinned by digest, and a range is
|
||||
|
||||
@@ -39,12 +39,28 @@ way ([ADR 0074](../../02-DECISIONS/0074-the-wire-is-specified-not-the-types.md))
|
||||
repository does, the Rust and Python ones will do, so the shape is worth getting right before there
|
||||
are four of them.
|
||||
|
||||
## It is a violation, not an open question
|
||||
|
||||
[ADR 0014](../../02-DECISIONS/0014-no-npm-workspace.md) already decided this, and was accepted:
|
||||
|
||||
> Each module is an independent package that declares its dependencies and **consumes them from
|
||||
> the private registry, including the mesh's own shared library.** A cross-package change is
|
||||
> therefore two steps: publish the producer, then consume it.
|
||||
|
||||
So a git dependency at a pinned commit is not an alternative mechanism under consideration. It is
|
||||
the mesh's own shared library being consumed by a means the record rules out, and the lock naming
|
||||
a sibling directory is what that looks like when nobody publishes.
|
||||
|
||||
**Which makes the fix a direction rather than a discussion**: publish the SDK to the private
|
||||
registry, consume it by version, and the lock stops being able to name a path that exists on one
|
||||
machine.
|
||||
|
||||
## Open questions
|
||||
|
||||
- **Is a git dependency at a pinned commit the intended mechanism?** It works, needs no package
|
||||
registry, and reuses the forge a mesh already depends on to exist at all
|
||||
([ADR 0071](../../02-DECISIONS/0071-where-genesis-gets-its-source.md)). If so, the lock should say
|
||||
so and the sibling path should never have been committed.
|
||||
- **Which private registry, and does the bootstrap have one?** The catalogue holds `verdaccio`;
|
||||
a git host typically serves package registries too. ADR 0014 says *the* private registry as
|
||||
though there is one, and today a fresh mesh has neither until something installs it — so the
|
||||
first SDK build happens before the registry the record assumes.
|
||||
- **Or should the SDK be a published package?** The catalogue holds a private registry module, and a
|
||||
published package is how the rest of the world does this — at the cost of a mesh needing that
|
||||
registry up before it can build anything, which is a bootstrap problem where there is currently
|
||||
|
||||
Reference in New Issue
Block a user