lhumina_code/hero_macros_previous
0
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

make development compatible with main and other way around #1

New issue
Open
opened 2026-06-05 14:39:59 +00:00 by despiegk · 3 comments
despiegk commented 2026-06-05 14:39:59 +00:00
Owner
Copy link
  • move all macros and supporting code to this repo
  • use mass update action on main to make sure we use these new macro's
  • no more dependency on hero_blueprint because this one is too new

so this will allow us to bring main back into development

and be compatible so we can easier make progress and move project per project over

checks

  • no repo (apart from _lib and _blueprint) uses _lib for derive and _blueprint
  • these repo's all use this macros_previous repo
- move all macros and supporting code to this repo - use mass update action on main to make sure we use these new macro's - no more dependency on hero_blueprint because this one is too new so this will allow us to bring main back into development and be compatible so we can easier make progress and move project per project over ## checks - [ ] no repo (apart from _lib and _blueprint) uses _lib for derive and _blueprint - [ ] these repo's all use this macros_previous repo
mik-tf commented 2026-06-05 16:18:34 +00:00
Owner
Copy link

A few notes from the meeting to add on top of this, not replacing anything above.

On the old vs new question: this repo holds the previous, stable macros, the versions main already works with, not the latest fast moving ones. The name previous means the older known good set. The newer macros stay in hero_lib and hero_blueprint and keep evolving. Main pins this repo so it stops breaking when those change, and each repo migrates onto the new library one by one later. When the issue says use these new macros, new means the macros now living in this new repo, not a newer version.

  • The supporting code to move into this repo includes the OpenRPC clients, not only the derive macros. The aim is that main imports all of it from here.
  • Sequencing: once main pins this repo and no longer references the repos we are upgrading, those repos can be upgraded one by one without breaking main. Main stays on the stable set here while each project moves over on its own schedule.
  • The payoff is two-way. After main folds back into development, development is a superset of main, so a new version of something built on development can also go to main.
  • Suggested acceptance check to add: main builds and runs with this repo as the only source of macros, with no hero_blueprint dependency.

Signed-by: mik-tf mik-tf@noreply.invalid

A few notes from the meeting to add on top of this, not replacing anything above. On the old vs new question: this repo holds the previous, stable macros, the versions main already works with, not the latest fast moving ones. The name previous means the older known good set. The newer macros stay in hero_lib and hero_blueprint and keep evolving. Main pins this repo so it stops breaking when those change, and each repo migrates onto the new library one by one later. When the issue says use these new macros, new means the macros now living in this new repo, not a newer version. - The supporting code to move into this repo includes the OpenRPC clients, not only the derive macros. The aim is that main imports all of it from here. - Sequencing: once main pins this repo and no longer references the repos we are upgrading, those repos can be upgraded one by one without breaking main. Main stays on the stable set here while each project moves over on its own schedule. - The payoff is two-way. After main folds back into development, development is a superset of main, so a new version of something built on development can also go to main. - Suggested acceptance check to add: main builds and runs with this repo as the only source of macros, with no hero_blueprint dependency. Signed-by: mik-tf <mik-tf@noreply.invalid>
mik-tf commented 2026-06-05 16:21:13 +00:00
Owner
Copy link

Summary of the task

The problem

Today the derive macros and their supporting code, including the OpenRPC clients, live in hero_lib and hero_blueprint. Those repos move fast and get big updates, and hero_blueprint in particular is too new for main. If we bring the current hero_lib and hero_blueprint into main, main stops building. So main and development have drifted apart and work gets stuck on one side.

The plan

  1. This repo, hero_macros_previous, holds the previous stable macros and supporting code, the versions main already works with. Previous means the older known-good set, not the latest fast-moving one. The newer macros stay in hero_lib and hero_blueprint and keep evolving.
  2. Move that stable set into this repo: the derive macros and the OpenRPC clients.
  3. Run a mass update on main with the orchestrator so every repo depends on this repo instead of hero_lib for derive and hero_blueprint. After this, main imports everything macro related from here and has no dependency on hero_blueprint.
  4. Because main is now pinned to this stable set and no longer references the repos we are upgrading, those repos can be upgraded one by one without breaking main. Each project moves over on its own schedule.
  5. Once everything on main uses this repo, fold main back into development. development becomes a superset of main, so a new version of something built on development can also go to main.

The payoff

main builds and stays live again, which is what the sandbox needs to deploy from main. The two-way flow between main and development is restored, so newer work can reach the sandbox once each piece has moved over.

Checks

  • no repo, apart from hero_lib and hero_blueprint themselves, uses hero_lib for derive or hero_blueprint
  • all those repos use this hero_macros_previous repo
  • main builds and runs with this repo as the only source of macros, with no hero_blueprint dependency

Signed-by: mik-tf mik-tf@noreply.invalid

## Summary of the task ### The problem Today the derive macros and their supporting code, including the OpenRPC clients, live in hero_lib and hero_blueprint. Those repos move fast and get big updates, and hero_blueprint in particular is too new for main. If we bring the current hero_lib and hero_blueprint into main, main stops building. So main and development have drifted apart and work gets stuck on one side. ### The plan 1. This repo, hero_macros_previous, holds the previous stable macros and supporting code, the versions main already works with. Previous means the older known-good set, not the latest fast-moving one. The newer macros stay in hero_lib and hero_blueprint and keep evolving. 2. Move that stable set into this repo: the derive macros and the OpenRPC clients. 3. Run a mass update on main with the orchestrator so every repo depends on this repo instead of hero_lib for derive and hero_blueprint. After this, main imports everything macro related from here and has no dependency on hero_blueprint. 4. Because main is now pinned to this stable set and no longer references the repos we are upgrading, those repos can be upgraded one by one without breaking main. Each project moves over on its own schedule. 5. Once everything on main uses this repo, fold main back into development. development becomes a superset of main, so a new version of something built on development can also go to main. ### The payoff main builds and stays live again, which is what the sandbox needs to deploy from main. The two-way flow between main and development is restored, so newer work can reach the sandbox once each piece has moved over. ### Checks - [ ] no repo, apart from hero_lib and hero_blueprint themselves, uses hero_lib for derive or hero_blueprint - [ ] all those repos use this hero_macros_previous repo - [ ] main builds and runs with this repo as the only source of macros, with no hero_blueprint dependency Signed-by: mik-tf <mik-tf@noreply.invalid>
scott commented 2026-06-06 02:22:34 +00:00
Owner
Copy link

Status report — hero_macros_previous freeze rollout

What this repo now provides

A frozen, self-contained snapshot of the macro/codegen toolchain so consumer repos stop tracking the still-moving hero_lib / hero_blueprint. Two branches, mirroring hero_lib:

  • main — old hero_rpc stack re-cut from the pre-bridge hero_blueprint@d31c7b6 (client macros emit ::hero_rpc2::, herolib-free) + a frozen new-gen derive hero_derive (from hero_lib@9657556a).
  • development — same old stack + hero_derive cut from hero_lib@d1383f58 (for consumers that pinned herolib_derive@development).

Both branches build green and carry zero git=hero_lib/hero_blueprint dependencies.

Migration recipes (mechanical, no source changes)

  • New-stack repos: herolib_derive = { package = "hero_derive", git = .../hero_macros_previous.git, branch = <same branch the repo pinned> }. All other herolib_* left live — the frozen macro emits against the consumer's live runtime, so hero_lib keeps moving. The package = rename avoids colliding with the herolib_derive that live herolib_core pulls transitively.
  • Old-stack repos: repoint hero_rpc_derive / hero_rpc_openrpc → hero_macros_previous, and add hero_rpc2 (the pre-bridge client macro emits ::hero_rpc2::, so it must be declared). Fully self-contained afterwards.

Rollout result (branch development_freeze pushed per repo; only that branch pushed)

✅ DONE — frozen + builds green, development_freeze pushed (8):
hero_shrimp, hero_redis (= hero_db), hero_planner, hero_code, hero_codescalers, hero_gpu, hero_indexer, hero_slides

⚠️ PARTIAL — integration freeze builds, but the repo's development branch is broken independent of this change (2):
hero_browser, hero_proc (e.g. proc dev references herolib_core::logger::LogDeleteScope, missing at its pinned hero_lib). Frozen on integration locally; dev held until their dev baseline is fixed.

⚪ NOOP — no herolib_derive/hero_rpc git dep, nothing to do (~19):
whiteboard, skills, archipelagos, biz, code_indexer, forge, foundry, kimi, kimi_rust, ledger, mail, researcher, router, webbuilder, website_framework, + non-Rust repos (builder, compute_config, compute_registry, deployment_docker).

⏸ DEFERRED — Blocker B (11): these don't build at baseline on integration, because they transitively pull a broken hero_rpc_derive from hero_blueprint/hero_rpc (mid-teardown) via other hero SDKs, or their own source uses old transport types:
agent, books, office, orchestrator, voice, proxy (transitive dual-source), editor (own source uses hero_rpc_openrpc::OpenRpcError), lib_rhai (complex mixed), wallet, voice_provider, matrixchat (baseline-broken via transitive blueprint dep).

⏸ TIER-3 — schema/server-macro adopters, deferred for team judgement (7):
compute, drive, logic, mycelium, os, osis, livekit (committed generated #[derive(OsisObject)] / inline server code — can't go self-contained; need the frozen hero_derive superset + live runtime).

Checklist status

  • no repo (apart from _lib and _blueprint) uses _lib for derive and _blueprint — 8/~41 done; the frozen hero_derive alias removes the direct moving-derive dependency on those. Remaining repos are Blocker-B (need their broken transitive hero_rpc SDK deps fixed first) or Tier-3.
  • these repos all use this macros_previous repo — in progress (8 pushed on development_freeze).

Key finding / next step

The dominant blocker is not the macro swap itself — it's that many integration repos don't build at baseline because they transitively depend on broken hero_blueprint/hero_rpc crates left mid-teardown. The freeze succeeds cleanly wherever the repo builds. Recommended next: fix that root cause (extend the freeze/[patch] to the leaf SDKs like hero_*_sdk that still pull hero_rpc_derive from blueprint), which should unblock most of the deferred set, then take Tier-3 with the team.

Nothing else pushed; all consumer changes are local on development_freeze branches pending review.

## Status report — `hero_macros_previous` freeze rollout ### What this repo now provides A **frozen, self-contained snapshot** of the macro/codegen toolchain so consumer repos stop tracking the still-moving `hero_lib` / `hero_blueprint`. Two branches, mirroring hero_lib: - **`main`** — old `hero_rpc` stack re-cut from the **pre-bridge** `hero_blueprint@d31c7b6` (client macros emit `::hero_rpc2::`, herolib-free) **+** a frozen new-gen derive `hero_derive` (from `hero_lib@9657556a`). - **`development`** — same old stack + `hero_derive` cut from `hero_lib@d1383f58` (for consumers that pinned `herolib_derive@development`). Both branches build green and carry **zero `git=hero_lib`/`hero_blueprint` dependencies**. ### Migration recipes (mechanical, no source changes) - **New-stack repos:** `herolib_derive = { package = "hero_derive", git = .../hero_macros_previous.git, branch = <same branch the repo pinned> }`. All other `herolib_*` left **live** — the frozen macro emits against the consumer's live runtime, so hero_lib keeps moving. The `package =` rename avoids colliding with the `herolib_derive` that live `herolib_core` pulls transitively. - **Old-stack repos:** repoint `hero_rpc_derive` / `hero_rpc_openrpc` → `hero_macros_previous`, **and add `hero_rpc2`** (the pre-bridge client macro emits `::hero_rpc2::`, so it must be declared). Fully self-contained afterwards. ### Rollout result (branch `development_freeze` pushed per repo; **only that branch pushed**) **✅ DONE — frozen + builds green, `development_freeze` pushed (8):** `hero_shrimp`, `hero_redis` (= `hero_db`), `hero_planner`, `hero_code`, `hero_codescalers`, `hero_gpu`, `hero_indexer`, `hero_slides` **⚠️ PARTIAL — integration freeze builds, but the repo's `development` branch is broken *independent of this change* (2):** `hero_browser`, `hero_proc` (e.g. proc dev references `herolib_core::logger::LogDeleteScope`, missing at its pinned hero_lib). Frozen on integration locally; dev held until their dev baseline is fixed. **⚪ NOOP — no `herolib_derive`/`hero_rpc` git dep, nothing to do (~19):** whiteboard, skills, archipelagos, biz, code_indexer, forge, foundry, kimi, kimi_rust, ledger, mail, researcher, router, webbuilder, website_framework, + non-Rust repos (builder, compute_config, compute_registry, deployment_docker). **⏸ DEFERRED — Blocker B (11):** these don't build at baseline on integration, because they transitively pull a **broken** `hero_rpc_derive` from `hero_blueprint`/`hero_rpc` (mid-teardown) via other hero SDKs, or their own source uses old transport types: `agent`, `books`, `office`, `orchestrator`, `voice`, `proxy` (transitive dual-source), `editor` (own source uses `hero_rpc_openrpc::OpenRpcError`), `lib_rhai` (complex mixed), `wallet`, `voice_provider`, `matrixchat` (baseline-broken via transitive blueprint dep). **⏸ TIER-3 — schema/server-macro adopters, deferred for team judgement (7):** `compute`, `drive`, `logic`, `mycelium`, `os`, `osis`, `livekit` (committed generated `#[derive(OsisObject)]` / inline server code — can't go self-contained; need the frozen `hero_derive` superset + live runtime). ### Checklist status - [ ] *no repo (apart from \_lib and \_blueprint) uses \_lib for derive and \_blueprint* — **8/~41 done**; the frozen `hero_derive` alias removes the direct moving-derive dependency on those. Remaining repos are Blocker-B (need their broken transitive `hero_rpc` SDK deps fixed first) or Tier-3. - [ ] *these repos all use this `macros_previous` repo* — **in progress** (8 pushed on `development_freeze`). ### Key finding / next step The dominant blocker is **not** the macro swap itself — it's that **many integration repos don't build at baseline** because they transitively depend on broken `hero_blueprint`/`hero_rpc` crates left mid-teardown. The freeze succeeds cleanly wherever the repo builds. Recommended next: fix that root cause (extend the freeze/`[patch]` to the leaf SDKs like `hero_*_sdk` that still pull `hero_rpc_derive` from blueprint), which should unblock most of the deferred set, then take Tier-3 with the team. *Nothing else pushed; all consumer changes are local on `development_freeze` branches pending review.*
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
osis_oserver
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
scott
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_macros_previous#1
No description provided.