Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Feature]: Python: `from module import symbol` across repositories is dropped, not parked (#3152 for Python)

Aperta
  • Qualcosa non va?
#3,744 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
devtools

Direzione di ricerca

Start by reproducing the separate-repository and joint-scan commands in the issue, then read symbol_resolution.py::resolve_python_import_guided_calls and cross_repo_calls.py. Trace how metadata.unresolved_calls reaches merge-graphs and global_graph.py::global_add, including _LANG_SUFFIXES. Done means a unique cross-repository module match restores the import and calls, while ambiguous stems create no edges and Python names cannot bind across languages.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement
Problem or use case

Two Python repositories. One imports a function from the other and calls it. Each repository is built on its own, then the two graphs are combined with merge-graphs or global add. The combined graph has no edge between the repositories: the imports_from edge ends on a sourceless placeholder, and the call is not in the graph at all. The same two files scanned as one directory produce both edges.

This is the Python shape of #3152. Java, C++, C# and Swift park a member call whose receiver type lives elsewhere (#3222), and #3384, #3386, #3388, #3390, #3393 extend that per language. Python is missing from the series, and its dependency shape is different: not obj.method() bound through a receiver type, but from module import symbol plus a plain call, which symbol_resolution.py binds by (module_stem, symbol) inside one build and drops otherwise.

Proposed solution
  1. Python extractor: when from module import symbol cannot be resolved in the corpus, park it on the importing file node, and park the raw calls that use the imported name (or its alias) on the caller node, names only, in the same spirit as _park_unresolved_member_call.
  2. Merge pass: for a parked module, find exactly one file node in another repo with that module stem; rewire the imports_from edge and emit calls edges for the parked names. Ambiguous stems fabricate nothing.
  3. Add "python": frozenset({".py"}) to _LANG_SUFFIXES so a Python name never binds to a same-named declaration in another language.

Package-level imports (from pkg.sub import x, import pkg) would follow the same rule with the package directory as the stem; the single-module case above is the minimal one.

Related

#3152, #3222 (mechanism), #3384 #3386 #3388 #3390 #3393 (per-language series, Python missing), #3665 (unresolved call indistinguishable from none), #3414 #3415 #3360 (false cross-repo edges from stub dedupe), #3578 (shared type linking for global add, types only).

Alternatives considered

No response

Area

Extraction or language support

Additional context
lib_repo/config_validator.py
    def validator_from_json(data):
        return ConfDict(data)

    class ConfDict:
        def __init__(self, data):
            self.data = data

app_repo/app.py
    from config_validator import validator_from_json

    def load(payload):
        return validator_from_json(payload)

$ (cd lib_repo && git init -q && graphify update . --no-cluster)   # 4 nodes, 4 edges
$ (cd app_repo && git init -q && graphify update . --no-cluster)   # 2 nodes, 2 edges
$ graphify merge-graphs lib_repo/graphify-out/graph.json app_repo/graphify-out/graph.json --out merged.json

merged.json: 7 nodes, 6 edges, 0 edges between the repos.

app_repo::app  -imports_from->  app_repo::config_validator      # placeholder, no source_file
app_repo::app  -contains->      app_repo::app_load               # no calls edge at all

Control, both files in one directory:

$ graphify update joint --no-cluster                              # 6 nodes, 8 edges
app       -imports->  config_validator_validator_from_json
app_load  -calls->    config_validator_validator_from_json
Expected

After merge-graphs or global add:

app_repo::app -imports_from-> lib_repo::config_validator (the file node whose module stem matches the placeholder, when exactly one repo provides it);
app_repo::app_load -calls-> lib_repo::config_validator_validator_from_json, tagged like _cross_repo_call, under the same single-definition guard the in-repo resolver uses.
Where it stops today
symbol_resolution.py::resolve_python_import_guided_calls resolves from module import symbol by (module_stem, symbol) in the current corpus and drops the call when the module is absent. Nothing is written to graph.json, so no merge-time pass can recover it (same root cause as #3152, and the invisibility #3665 describes).
cross_repo_calls.py reads metadata.unresolved_calls, but only receiver-typed member calls are parked, and _LANG_SUFFIXES lists cpp, csharp, java, swift.
global_graph.py::global_add deduplicates sourceless stubs by label among stubs only; a stub is never compared with a file node of another repo. What that dedupe does produce is the false cross-repo edges of #3414 and #3360: on five internal Python repositories, 831 edges between repos, all through shared stubs like Any, Enum, BaseModel, none between two real files. The one real dependency between those repos (a service importing an in-house library in three files) gave no edge; a joint scan of the same two repos gave 25.

Lingua principale
Python
Stelle
124k
Fork
11.9k
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Graphify-Labs/graphify

Tutte le issue di Graphify-Labs/graphify

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.