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

Python: `module.func()` calls through a module loaded with `importlib.util.spec_from_file_location` are no longer traced (0.10.8 → 0.11.0, still in 0.12.0)

Aperta
  • Qualcosa non va?
#2,659 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
56/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
backend-api-design, developer-experience

Direzione di ricerca

Start by tracing how Python call relationships are indexed and how trace_path resolves inbound callers; the issue does not name source files or tests. Compare the reproduced importlib.util.spec_from_file_location case across versions with the static import case. Done when the intended behavior is clarified and a regression test captures the result.

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

Descrizione

bug editor/integration parsing/quality

Disclosure: this issue was written and posted by an AI agent (Claude Code) acting on behalf of @benjaminge73. The reproduction below was run by the agent on all three versions before posting; the outputs are copied from those runs.

Version

Tested with the official darwin-arm64 release archives (SHA-256 checked against checksums.txt):

Version Callers of compute_total found
0.10.8 2 (uses_direct, uses_via_importlib)
0.11.0 1 (uses_direct only)
0.12.0 1 (uses_direct only)

Platform: macOS (Apple Silicon). Install channel: GitHub release archive. Binary variant: standard.

What happened, and what did you expect?

In Python, a function that is called as module.func() where module was loaded with importlib.util.spec_from_file_location + module_from_spec + exec_module was traced as an inbound caller in 0.10.8. Since 0.11.0, trace_path (direction: inbound) no longer returns that caller. The statically imported caller is still found.

I expected the same result as 0.10.8 (2 callers). I do not know whether the drop is intentional (for example a precision change; the 0.12.0 notes mention that external imports are no longer bound to same-named project symbols), so I am reporting it as a behavior change in case it is not.

Why it matters: this is the standard way to test a script that is not a package (load_module() helper, then module.func(...) in each test). In one of my projects roughly 90 of 140 test files load their target this way, so trace_path ... include_tests lost most of the test callers of a symbol (13 callers in 0.10.8, 1 in 0.11.0 and 0.12.0). I pinned 0.10.8 because of it.

Reproduction

No proprietary code: the script below builds a 3-file dummy project in a temp dir, indexes it and traces the callers. Run it once per binary (HOME is a temp dir, nothing on your machine is touched):

#!/usr/bin/env bash
# usage: BIN=/path/to/codebase-memory-mcp ./repro.sh
set -euo pipefail
export HOME="$(mktemp -d)"
D="$(mktemp -d)"; cd "$D"; D="$(pwd -P)"
mkdir pkg && touch pkg/__init__.py
cat > pkg/target.py <<'PY'
def compute_total(values):
    return sum(values)
PY
cat > pkg/direct.py <<'PY'
from pkg.target import compute_total


def uses_direct():
    return compute_total([1, 2])
PY
cat > pkg/dynamic.py <<'PY'
import importlib.util
from pathlib import Path


def load():
    spec = importlib.util.spec_from_file_location("target", Path(__file__).parent / "target.py")
    module = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(module)
    return module


def uses_via_importlib():
    module = load()
    return module.compute_total([3, 4])
PY
git init -q . && git add -A && git -c user.email=a@b -c user.name=x commit -qm fixture
"$BIN" --version
"$BIN" cli index_repository "{\"repo_path\":\"$D\",\"mode\":\"full\"}" >/dev/null 2>&1
PROJECT="$(echo "$D" | sed 's|^/||; s|/|-|g')"
"$BIN" cli trace_path "{\"function_name\":\"compute_total\",\"project\":\"$PROJECT\",\"direction\":\"inbound\",\"depth\":1}" 2>/dev/null

Output with 0.10.8:

codebase-memory-mcp 0.10.8
function: compute_total
direction: inbound
callers_total: 2
  ...pkg.direct:   uses_direct 1
  ...pkg.dynamic:  uses_via_importlib 1

Output with 0.11.0 and 0.12.0:

callers_total: 1
callers_total_relation: eq
  ...pkg.direct.uses_direct 1

(The raw-JSON form of cli prints a deprecation warning in 0.12.0; it still works and I kept it so the same script runs on all three versions.)

Project scale

Tiny: 3 Python files. The same drop shows on a real project (about 10k nodes, 40k edges).

Confirmations
  • I searched existing issues and this is not a duplicate. (Closest ones: #1237, #1271, #1153 — they are about static imports, polymorphism and instance methods, not about modules loaded with importlib.)
  • My reproduction uses shareable code (a dummy snippet), not proprietary code.
Lingua principale
C
Stelle
45.8k
Fork
3.8k
Merge medio
3g 11h
PR unite (30g)
201

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 DeusData/codebase-memory-mcp

Tutte le issue di DeusData/codebase-memory-mcp

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.