fix: keep same-username homes on different hosts distinct - #641
Merged
Conversation
Two standalone homes sharing a username but bound to different hosts had identical id_hash values, so id_hash-keyed entity resolution could not distinguish them. Use the registry key and system as the explicit home identity. This keeps identity independent of user-overridable presentation metadata while preserving uniqueness for the same registry key across systems. AI-assisted: GitLab Duo Agentic Chat (GPT-5.6 Sol)
Two standalone homes sharing a username but bound to different hosts (user@hostA, user@hostB) collapsed onto a single pipeline scope: mkScopeId rendered an entity value as v.name, and a home's name is force-set to the bare user name, so both rendered home=user. Their collected class content merged and each flake output yielded the other's configuration. Entities now expose __scopeName, their registry key, which is unique per kind per system. mkScopeId prefers it and falls back to name, so only kinds that rewrite name behave differently, and scope ids stay readable in traces and error messages. This is a separate keying layer from the parent commit's id_hash fix, and neither alone is sufficient: id_hash keys the edge layer, where entity scopes are named "<kind>:<id_hash>" and same-name siblings collapse by design, while mkScopeId keys the resolution pipeline and never read id_hash. The added regression suite therefore needs both commits. AI-assisted: Claude Code (opus-5)
Member
|
at first glance, changes look good to me, however I'd like to know if @sini is ok with them, my only question is if we do have to keep the |
Collaborator
|
A good question, @vic. Not one I think we need to block acceptance on. Given my intention is to replace this system soon I'm inclined to simply accept this contribution as-is. |
sini
approved these changes
Jul 29, 2026
vic
approved these changes
Jul 30, 2026
Contributor
Author
|
Thank you very much for the quick review |
worldofgeese
added a commit
to worldofgeese/den
that referenced
this pull request
Aug 1, 2026
Picks up denful/den#641 (same-username homes on different hosts stay distinct) and #643 (four silent-drop defects in forward classes and standalone homes). Only #643's fix for {user, ...} being dropped on standalone homes touches us -- den.homes.x86_64-linux.worldofgeese is our only standalone home -- and worldofgeese evaluates identically before and after (username, homeDirectory, 85 packages, stateVersion). just check passes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hello, I'm migrating my nix config to den and found that when home-manager and the OS are managed as separate outputs, a few strange things will happen.
Two standalone home configs that share a username but target different hosts (
user@hostA,user@hostB) were stepping on each other: each flake output ended up with the other's configuration.The cause was that a home's
nameis deliberately force-set to the bare username, and den used thatnameas an entity's identity in two separate places: theid_hashused by the edge layer and the scope string built bymkScopeIdin the resolution pipeline. So both homes looked identical and collapsed onto one another.This PR gives entities a distinct internal identity (
__scopeName, the full registry key likeuser@hostA) and teaches both keying layers to use it, so same-username homes on different hosts stay cleanly separated while their user-facing name and description are untouched.It ships as two commits (one per keying layer, since both are needed) plus regression tests covering the
id_hashand scope paths.