Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de 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)

Abierto
  • ¿Algo no está bien?
#2,659 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
56/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend-api-design, developer-experience

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
C
Estrellas
45.8k
Forks
3.8k
Merge medio
3 d 4 h
PR fusionados (30 d)
208

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de DeusData/codebase-memory-mcp

Todos los issues de DeusData/codebase-memory-mcp

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.