[V2:03] Add Repository Manifest Identity by ritorhymes · Pull Request #17 · eips-wg/preprocessor

ritorhymes · 2026-05-05T07:44:43Z

Part of V2: Multi-repo local build system.

Summary

This PR adds the manifest-backed repository identity layer that later workspace lifecycle and execution-policy PRs consume. It introduces the .build-eips.repo.toml schema with validation and an ActiveRepoIdentity selector that prefers a manifest when present and falls back to legacy EIPs/ERCs config; nothing in main.rs calls this yet, so review should focus on schema rules and fallback semantics rather than integration.

Add the .build-eips.repo.toml schema for active proposal repositories and declared sibling repositories.
Add manifest loading, validation, parse errors, and schema tests.
Add ActiveRepoIdentity for selecting either manifest-backed identity or the legacy EIPs/ERCs fallback.
Add the tempfile dev dependency used by manifest tests.

Rationale

The manifest is tracked proposal-repo identity and sibling topology, not general local fork configuration. The existing identifying_commit fallback fits the legacy EIPs/ERCs-only architecture, but the local build system needs repo-owned identity data once it operates inside a multi-repo workspace.

Keeping this in tracked repo metadata lets build, serve, init, doctor, and execution-policy resolution identify the active proposal repo and its sibling repos without hardcoding every repo relationship into the preprocessor binary. Theme remains shared workspace infrastructure at workspace/theme, and local execution preferences remain in .build-eips.toml.

Review Notes

This PR defines the manifest-backed identity model; it does not complete adoption by itself. The EIPs/ERCs rollout PRs (V2:20 and V2:21) add the tracked .build-eips.repo.toml files that make those repos use this path. Until a repo carries that manifest, the legacy EIPs/ERCs fallback remains available.

Later workspace lifecycle PRs (V2:06-V2:07) and execution policy V2:08 consume this layer to identify the active repo, discover sibling repos, and resolve repository metadata.

Review config.rs for the manifest schema and validation rules. Review identity.rs for the fallback behavior: repositories with a manifest use that metadata, while existing EIPs/ERCs-style repositories can still resolve through legacy config.

ActiveRepoIdentity::load is defined here but not yet called from main.rs; the workspace lifecycle and execution policy PRs wire it in. Manifest-backed accessors such as RepoManifest::sibling_repositories are also foundation in this slice and are consumed by those later PRs.

Security note: identity assertion shifts from “the binary recognizes you by commit content” to “the repo declares its identity in tracked metadata.” The security boundary is the same in both cases: you trust the checkout you ran the preprocessor on. The new model is explicit and reviewable rather than implicit, and reserved repo ids (theme, preprocessor, eipw) prevent shadowing workspace infrastructure.

Verification

Review src/config.rs for .build-eips.repo.toml parsing, validation, and tests.
Review src/identity.rs for manifest-backed identity selection and legacy fallback behavior.
Review the manifest validation tests for reserved repo ids, safe repo keys, self-sibling rejection, and duplicate sibling repository detection.
Review Cargo.toml and Cargo.lock for the tempfile test dependency.

SamWilsn

So this makes the preprocessor very configurable. Do we need this level of complexity?

Is the point to allow someone to point the preprocessor at their own forks of our repositories? I'm just struggling a bit to see what the use case for this will be.

SamWilsn · 2026-05-12T23:19:12Z

+#[derive(Debug, Snafu)]
+pub enum RepoManifestError {
+    #[snafu(display("i/o error while accessing `{}`", path.to_string_lossy()))]
+    RepoFs {


Suggested change

RepoFs {

Io {

SamWilsn · 2026-05-12T23:19:28Z

+        "unable to parse repo manifest `{}`",
+        manifest_path.to_string_lossy()
+    ))]
+    RepoParse {


Suggested change

RepoParse {

Parse {

SamWilsn · 2026-05-25T21:03:29Z

+    }
+}
+
+fn required_manifest_value<T>(


This should be a member of RepoManifest (unless it's used elsewhere and I missed it).

SamWilsn · 2026-05-25T21:07:59Z

+    pub fn active_endpoint(&self, staging: bool) -> RepositoryEndpoint {
+        if staging {
+            self.staging.clone()
+        } else {
+            self.production.clone()
+        }
+    }


Suggested change

pub fn active_endpoint(&self, staging: bool) -> RepositoryEndpoint {

if staging {

self.staging.clone()

} else {

self.production.clone()

}

}

pub fn active_endpoint(&self, staging: bool) -> &RepositoryEndpoint {

if staging {

&self.staging

} else {

&self.production

}

}

Unless there's a reason not to?

SamWilsn · 2026-05-25T21:09:29Z

+    })
+}
+
+fn validate_repo_key(


Same here. The validate functions should be private members of the struct that needs them.

Add the .build-eips.repo.toml schema, loader, validation rules, and manifest tests for active proposal repositories and declared sibling repositories. Introduce ActiveRepoIdentity so later workspace lifecycle and execution layers can select manifest-backed repository metadata while the legacy EIPs/ERCs fallback continues to operate.

ritorhymes · 2026-05-26T02:13:27Z

So this makes the preprocessor very configurable. Do we need this level of complexity?

Is the point to allow someone to point the preprocessor at their own forks of our repositories? I'm just struggling a bit to see what the use case for this will be.

This is not meant to make arbitrary forks first-class through local config. It is meant to move proposal-repo identity and sibling topology out of hardcoded preprocessor config and into tracked repo metadata, because the local build system needs that information to operate inside a multi-repo workspace. Theme is intentionally kept out of this and remains shared workspace infrastructure at workspace/theme; local execution preferences stay in .build-eips.toml.

The current identifying_commit system fits the old architecture because the preprocessor had a small, fixed universe: EIPs and ERCs. The binary could centrally know both repos, their URLs, their base URLs, and a commit unique enough to identify each one without requiring repo-owned metadata.

The limitation shows up once the local build system lands, because the tool stops being just “render one of two known upstream repos” and becomes “operate inside a multi-repo workspace.” At that point it needs to know the active repo, sibling proposal repos, and staging/production endpoints so build, serve, init, doctor, and execution-policy resolution can derive the right workspace layout and repository sources. Hardcoded binary config becomes friction there because every new proposal repo or split requires a code change and release before the local tooling can identify and wire it correctly.

The current identifying_commit lookup also becomes brittle for history-preserving splits. If, for example, Core splits out of EIPs, the new repo could inherit the existing EIPs identifying commit; making the legacy path work would require a coordinated preprocessor update with fresh post-split identifying commits for the affected repos. A tracked manifest avoids that by letting the repo declare its identity directly, and it also lets the split be exercised locally before a preprocessor release knows about it.

So this is not general fork configurability; it is the narrow tracked-data alternative to hardcoding each proposal repo and sibling relationship into the binary. The trade-off is that, in a multi-repo workspace, either the preprocessor remains the central authority for every repo relationship, or each proposal repo carries the tracked metadata needed to declare its own identity and reconnect to the larger build system. This PR chooses the repo-owned metadata path so new or split proposal repos do not require a preprocessor release before they can be identified locally.

ritorhymes · 2026-05-26T02:18:13Z

Pushed updates for the inline review items:

renamed the repo manifest error variants
moved manifest required-field and validation helpers onto RepoManifest
kept the manual required-field handling instead of adding optionable
changed active_endpoint to return a borrowed endpoint
rebased and pushed the dependent stack on top of this branch

I also updated the PR description with the rationale for the manifest layer.

ritorhymes changed the title ~~Add Repository Manifest Identity~~ [V2:03] Add Repository Manifest Identity May 5, 2026

This was referenced May 5, 2026

V2: Multi-repo local build system #15

Open

[V2:06] Add Workspace Init Baseline #20

Open

[V2:07] Add Workspace Doctor #21

Open

CI: [V2:20] Add Repo Manifest eips-wg/EIPs#11

Open

CI: [V2:21] Add Repo Manifest for ERCs eips-wg/ERCs#11

Open

ritorhymes force-pushed the v2/03-repo-manifest-identity branch 2 times, most recently from bb2c3ee to 786ba1e Compare May 9, 2026 20:10

SamWilsn reviewed May 25, 2026

View reviewed changes

ritorhymes force-pushed the v2/03-repo-manifest-identity branch from 786ba1e to 9fec377 Compare May 26, 2026 01:02

ritorhymes requested a review from SamWilsn May 26, 2026 08:36

ritorhymes mentioned this pull request Jun 13, 2026

Add repository manifest identity #43

Merged

SamWilsn closed this Jun 19, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[V2:03] Add Repository Manifest Identity#17

[V2:03] Add Repository Manifest Identity#17
ritorhymes wants to merge 1 commit into
eips-wg:masterfrom
ritovision:v2/03-repo-manifest-identity

ritorhymes commented May 5, 2026 •

edited

Loading

Uh oh!

SamWilsn left a comment

Uh oh!

SamWilsn May 12, 2026

Uh oh!

SamWilsn May 12, 2026

Uh oh!

SamWilsn May 25, 2026

Uh oh!

Uh oh!

SamWilsn May 25, 2026

Uh oh!

SamWilsn May 25, 2026

Uh oh!

ritorhymes commented May 26, 2026 •

edited

Loading

Uh oh!

ritorhymes commented May 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

ritorhymes commented May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Rationale

Review Notes

Verification

Uh oh!

SamWilsn left a comment

Choose a reason for hiding this comment

Uh oh!

SamWilsn May 12, 2026

Choose a reason for hiding this comment

Uh oh!

SamWilsn May 12, 2026

Choose a reason for hiding this comment

Uh oh!

SamWilsn May 25, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

SamWilsn May 25, 2026

Choose a reason for hiding this comment

Uh oh!

SamWilsn May 25, 2026

Choose a reason for hiding this comment

Uh oh!

ritorhymes commented May 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ritorhymes commented May 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ritorhymes commented May 5, 2026 •

edited

Loading

ritorhymes commented May 26, 2026 •

edited

Loading