Pre-flight checks
What happened?
extract_dmf (graphify/extractors/dm.py) mints each element id as _make_id(stem, "elem", current_window_nid, name). The window's node id already contains the file stem, and the stem is absolute at extraction time. extract()'s id remap (#502) rewrites only the leading stem, so the copy nested in the middle of the id keeps the absolute path.
Result on graphify's own tests/fixtures/sample.dmf (4 windows, 8 elements): every element id looks like
tests_fixtures_sample_elem_c_users_<user>_..._<checkout>_tests_fixtures_sample_window_infowindow_info
So the same repo gives different element ids in every clone, an update from a moved checkout cannot match the old ids, and the OS username lands in a committed graph.json (the same class as #1789 / #1899). Window ids are fine; only elements are affected.
Steps to reproduce
mkdir -p one/ui two/somewhere/ui
cp tests/fixtures/sample.dmf one/ui/skin.dmf
cp tests/fixtures/sample.dmf two/somewhere/ui/skin.dmf
graphify update one --force --no-cluster
graphify update two/somewhere --force --no-cluster
# compare the node ids in one/graphify-out/graph.json and two/somewhere/graphify-out/graph.json
Error output or graph output
Element ids from the same .dmf in two checkouts (0.9.77):
one/: ui_skin_elem_c_users_<user>_..._one_ui_skin_window_infowindow_info
two/: ui_skin_elem_c_users_<user>_..._two_somewhere_ui_skin_window_infowindow_info
All 8 element ids differ between the two checkouts; the 4 window ids and the file id match.
Graphify version
0.9.77 (5c7b847)
Operating System
Windows
Python Version
3.12
Installation Method
built from source (git clone)
Additional Environment Details
AST-only update, no provider environment variables set. A clean checkout of v8 at 5c7b847 reproduces it. Found while indexing graphify's own repo from two folders.
Additional context
Keying the element on the window name (what disambiguates elements anyway) removes the path. I have a fix with a regression test ready and will open a PR right after this.
Pre-flight checks
What happened?
extract_dmf(graphify/extractors/dm.py) mints each element id as_make_id(stem, "elem", current_window_nid, name). The window's node id already contains the file stem, and the stem is absolute at extraction time.extract()'s id remap (#502) rewrites only the leading stem, so the copy nested in the middle of the id keeps the absolute path.Result on graphify's own
tests/fixtures/sample.dmf(4 windows, 8 elements): every element id looks liketests_fixtures_sample_elem_c_users_<user>_..._<checkout>_tests_fixtures_sample_window_infowindow_infoSo the same repo gives different element ids in every clone, an
updatefrom a moved checkout cannot match the old ids, and the OS username lands in a committed graph.json (the same class as #1789 / #1899). Window ids are fine; only elements are affected.Steps to reproduce
mkdir -p one/ui two/somewhere/ui cp tests/fixtures/sample.dmf one/ui/skin.dmf cp tests/fixtures/sample.dmf two/somewhere/ui/skin.dmf graphify update one --force --no-cluster graphify update two/somewhere --force --no-cluster # compare the node ids in one/graphify-out/graph.json and two/somewhere/graphify-out/graph.jsonError output or graph output
Graphify version
0.9.77 (5c7b847)
Operating System
Windows
Python Version
3.12
Installation Method
built from source (git clone)
Additional Environment Details
AST-only
update, no provider environment variables set. A clean checkout ofv8at5c7b847reproduces it. Found while indexing graphify's own repo from two folders.Additional context
Keying the element on the window name (what disambiguates elements anyway) removes the path. I have a fix with a regression test ready and will open a PR right after this.