Pre-flight checks
What happened?
In _import_python (graphify/extract.py), a relative from .x import y whose module has no file behind it falls back to the attempted path (base / "x.py") and mints the target id from it: _make_id(str(target_path)). That path is absolute, and since no node exists for it the root-relative id remap never rewrites it. The checkout location and the OS username end up in graph.json, and every clone gets a different id for the same import.
An unresolved absolute import of the same module is already portable: from pkg.absent import y targets pkg_absent. So today from .absent and from pkg.absent in the same file point at two different ids, one of them machine-specific.
Graphify's own repo hits it: worked/mixed-corpus/raw/build.py does from .validate import validate_extraction and there is no validate.py next to it, so its graph carries c_users_<user>_..._worked_mixed_corpus_raw_validate_py.
(Same class as #2457 / #4154 for JS, but a separate Python code path; the existing comment there intends a missing sibling to stay dangling, which this keeps; only the id changes.)
Steps to reproduce
for d in clone_one somewhere_else/clone_two; do
mkdir -p $d/pkg && : > $d/pkg/__init__.py
printf "from .missing_rel import helper\nfrom . import missing_sibling\nimport missing_abs_mod\nfrom pkg.missing_pkg_mod import thing\n\n\ndef run():\n return helper(), thing()\n" > $d/pkg/app.py
graphify update $d --force --no-cluster
done
# compare node ids and edge endpoints of clone_one/ and somewhere_else/clone_two/
Error output or graph output
Ids from the two checkouts (0.9.77):
only in clone_one:
c_users_<user>_..._clone_one_pkg_missing_rel_py
in both checkouts:
missing_abs_mod
pkg_missing_pkg_mod
pkg_app, pkg_app_run, pkg_init
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
Fix ready: for a missing relative import, use the dotted module name relative to the scan root (pkg_missing_rel), the id the absolute form already gets; fall back to a ref id when the import climbs above the root. PR right after this.
Pre-flight checks
What happened?
In
_import_python(graphify/extract.py), a relativefrom .x import ywhose module has no file behind it falls back to the attempted path (base / "x.py") and mints the target id from it:_make_id(str(target_path)). That path is absolute, and since no node exists for it the root-relative id remap never rewrites it. The checkout location and the OS username end up in graph.json, and every clone gets a different id for the same import.An unresolved absolute import of the same module is already portable:
from pkg.absent import ytargetspkg_absent. So todayfrom .absentandfrom pkg.absentin the same file point at two different ids, one of them machine-specific.Graphify's own repo hits it:
worked/mixed-corpus/raw/build.pydoesfrom .validate import validate_extractionand there is novalidate.pynext to it, so its graph carriesc_users_<user>_..._worked_mixed_corpus_raw_validate_py.(Same class as #2457 / #4154 for JS, but a separate Python code path; the existing comment there intends a missing sibling to stay dangling, which this keeps; only the id changes.)
Steps to reproduce
Error 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
Fix ready: for a missing relative import, use the dotted module name relative to the scan root (
pkg_missing_rel), the id the absolute form already gets; fall back to arefid when the import climbs above the root. PR right after this.