bug: forge resolver picks hero_osis for hero_os on name-substring collision (forge.nu) #110

New issue

Closed

opened 2026-04-21 15:25:30 +00:00 by sameh-farouk · 0 comments

sameh-farouk commented

2026-04-21 15:25:30 +00:00

Member

Summary

forge pull lhumina_code/hero_os and service_os install both resolve to the wrong repo (hero_osis) when hero_osis is cloned locally and hero_os is not. Result: service_os install tries to cargo build hero_os binaries inside the hero_osis source tree, which has no such targets:

error: no bin target named `hero_os` in default-run packages
help: a target with a similar name exists: `hero_bot`

Steps to reproduce

# fresh env; service_osis install first clones hero_osis
service_osis install

# now request hero_os — resolver finds hero_osis via substring match
forge pull lhumina_code/hero_os   # "Already up to date" on hero_osis path
service_os install                # fails

Root cause

tools/modules/forge.nu:forge_resolve_local partial-match branch uses str contains -i $repo_part. For repo_part = "hero_os", this matches hero_osis because "hero_os" is a substring of "hero_osis".

The exact-name match above it only triggers when <coderoot>/hero_os already exists on disk — which it doesn't, since hero_osis got cloned first and the resolver then "finds" that as the local copy of hero_os.

Proposed fix

Rank exact-basename matches above substring matches in forge_resolve_local.
When multiple locally-cloned repos substring-match, prefer the one whose basename exactly equals repo_part; if none is exact, refuse and ask the user to be more specific.
Fall back to the API (which does know the exact name) before doing substring-match on local directory names.

Workaround

Clone the exact repo manually, bypassing the resolver:

forge_git clone https://forge.ourworld.tf/lhumina_code/hero_os.git $"($env.CODEROOT)/hero_os"
# then service_os install works, because exact-match hits first

Impact

Blocks every fresh install of hero_os on any host that cloned hero_osis first (which service_osis install does). Likely bites anyone bootstrapping the full stack.

### Summary `forge pull lhumina_code/hero_os` and `service_os install` both resolve to the wrong repo (`hero_osis`) when `hero_osis` is cloned locally and `hero_os` is not. Result: `service_os install` tries to `cargo build` hero_os binaries inside the hero_osis source tree, which has no such targets: ``` error: no bin target named `hero_os` in default-run packages help: a target with a similar name exists: `hero_bot` ``` ### Steps to reproduce ```nu # fresh env; service_osis install first clones hero_osis service_osis install # now request hero_os — resolver finds hero_osis via substring match forge pull lhumina_code/hero_os # "Already up to date" on hero_osis path service_os install # fails ``` ### Root cause `tools/modules/forge.nu:forge_resolve_local` partial-match branch uses `str contains -i $repo_part`. For `repo_part = "hero_os"`, this matches **`hero_osis`** because `"hero_os"` is a substring of `"hero_osis"`. The exact-name match above it only triggers when `<coderoot>/hero_os` already exists on disk — which it doesn't, since `hero_osis` got cloned first and the resolver then "finds" that as the local copy of `hero_os`. ### Proposed fix 1. Rank exact-basename matches above substring matches in `forge_resolve_local`. 2. When multiple locally-cloned repos substring-match, prefer the one whose basename exactly equals `repo_part`; if none is exact, refuse and ask the user to be more specific. 3. Fall back to the API (which does know the exact name) before doing substring-match on local directory names. ### Workaround Clone the exact repo manually, bypassing the resolver: ```nu forge_git clone https://forge.ourworld.tf/lhumina_code/hero_os.git $"($env.CODEROOT)/hero_os" # then service_os install works, because exact-match hits first ``` ### Impact Blocks every fresh install of `hero_os` on any host that cloned `hero_osis` first (which `service_osis install` does). Likely bites anyone bootstrapping the full stack.