graph_explorer/issues/0033b-vendor-python-functions.md at 4ef6a5f7dbf8f014e350b7ca858df784f0d0b4e0

Files

T

egutierrez 35ace544d9 docs(issues): roadmap fase 2 navegador + ports Go + runtime embebido

Anade siete issues que definen el camino para hacer graph_explorer
distribuible como binario Windows autocontenido (sin WSL):

- 0032 — browser_session enrichers via Playwright (login interactivo,
  cookies persistentes, fetch_webpage_browser, web_search_browser).
- 0033 — dispatcher multi-lenguaje (lang: go|python|bash en manifest)
  + runtime Python embebido en <app>/runtime/. 3 fases (A=dispatcher,
  B=runtime, C=UI badges).
- 0033b — vendoring de funciones Python por enricher (_vendored/ +
  .vendor.lock) para que los enrichers no dependan de registry_root
  en runtime.
- 0033c — fn check vendored: drift detection con --fix.
- 0033d — fn index lee python_runtime / python_runtime_deps de app.md.
- 0033e — /compile orquesta freeze + vendor + go builds.
- 0034 — port de los 5 enrichers de sistema a Go. Reusa funciones
  Go del registry directamente (no copias). Tests pytest existentes
  pasan sin cambios.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-02 16:10:35 +02:00

2.2 KiB

Raw Blame History

id, title, status, priority, created, depends_on

title

status

priority

created

depends_on

0033b

Vendoring de funciones Python por enricher

pending

high

2026-05-02

0033

Objetivo

Para que el .exe Windows sea portable a cualquier PC, los enrichers con lang: python no pueden importar de <registry_root>/python/functions/ en runtime. Cada enricher copia las funciones del registry que declara en uses_functions a <enricher>/_vendored/ durante el build, y run.py importa de ahi.

Implementacion

1. Script `tools/vendor_enricher_python.sh`

Recibe <enricher_dir> y <registry_root>. Lee uses_functions del manifest, filtra los IDs *_py_*, resuelve file_path desde registry.db, copia el .py a _vendored/<domain>/<name>.py y crea __init__.py por dominio. Genera .vendor.lock con <id> <sha256> <src_path> por linea. Idempotente: si el sha256 de origen coincide con el del lock, no copia.

2. Adaptacion de `run.py`

Cada enricher con lang: python que use funciones del registry cambia el import:

# antes
sys.path.insert(0, os.path.join(registry_root, "python", "functions"))
from cybersecurity.cybersecurity import normalize_url

# despues
sys.path.insert(0, os.path.join(os.path.dirname(__file__), "_vendored"))
from cybersecurity.normalize_url import normalize_url

3. .gitignore

Anadir _vendored/ y .vendor.lock al .gitignore del repo (o de cada app). Son artefactos de build, regenerables.

4. Hook al build

/compile (o el script de freeze del 0033) recorre apps/<app>/enrichers/*/manifest.yaml. Para cada manifest con lang: python, ejecuta vendor_enricher_python.sh.

Tests

Test unit del script bash: dado un manifest con dos uses_functions Python conocidas, verificar que _vendored/ queda con la estructura correcta y .vendor.lock lista los hashes.
Test e2e: fetch_webpage (lang: python) ejecuta correctamente con registry_root vacio en el ctx tras vendoring.

Definicion de hecho

tools/vendor_enricher_python.sh existe y es idempotente.
Cada enricher Python del proyecto tiene _vendored/ poblado y funciona sin registry_root en runtime.
El binario zippeado a Desktop arranca enrichers Python sin acceso al fn_registry.

2.2 KiB Raw Blame History