egutierrez
dbf5b45acd
- .mcp.json - bash/functions/pipelines/full_git_push.sh - python/pyproject.toml - python/uv.lock - bash/functions/infra/jupyter_mcp_serve.md - bash/functions/infra/jupyter_mcp_serve.sh - dev/issues/0166-app-to-app-dependencies-tracking.md Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
86 lines
3.3 KiB
Markdown
86 lines
3.3 KiB
Markdown
---
|
|
id: "0166"
|
|
title: "Rastrear dependencias entre apps (app→app) para clonado/build reproducible"
|
|
status: pendiente
|
|
type: enhancement
|
|
domain:
|
|
- registry-quality
|
|
- build
|
|
scope: registry-only
|
|
priority: media
|
|
depends: []
|
|
blocks: []
|
|
related: []
|
|
created: 2026-05-31
|
|
updated: 2026-05-31
|
|
tags: [build, apps, dependencies, clone, migration]
|
|
---
|
|
# 0166 — Rastrear dependencias entre apps (app→app)
|
|
|
|
## APP Metadata
|
|
|
|
| Campo | Valor |
|
|
|-------|-------|
|
|
| **ID** | 0166 |
|
|
| **Estado** | pendiente |
|
|
| **Prioridad** | media |
|
|
| **Tipo** | enhancement — metadata de apps + `fn app clone` / `fn doctor` |
|
|
|
|
## Contexto
|
|
|
|
Durante la migración a Linux nativo (PC `lucas-linux`, 2026-05-31) al levantar los
|
|
servicios systemd hubo que clonar+compilar los apps de servicio. El build de
|
|
**`sqlite_api`** (`projects/fn_monitoring/apps/sqlite_api`) falló con:
|
|
|
|
```
|
|
handlers.go:13:2: package fn-registry/apps/data_factory/datafactory is not in std
|
|
```
|
|
|
|
`sqlite_api` **importa un paquete de otro app** (`apps/data_factory/datafactory`).
|
|
Como `data_factory` no estaba clonado, no compilaba. Hubo que clonarlo a mano para
|
|
desbloquear el build. No hay forma declarada de saber, antes de clonar/compilar un app,
|
|
**qué otros apps necesita**.
|
|
|
|
## Problema
|
|
|
|
- `fn app clone <id>` clona solo el repo pedido; no arrastra los apps de los que depende.
|
|
- `fn sync locations` lista paths por PC pero no relaciones app→app.
|
|
- El grafo de dependencias entre apps es implícito (vive solo en los `import` de Go),
|
|
así que clonar el subset correcto en una máquina nueva es ensayo-error.
|
|
|
|
## Objetivo
|
|
|
|
Hacer explícitas y consultables las dependencias **app→app**, para que:
|
|
|
|
1. Se pueda **saber** qué apps dependen de qué apps (consulta / reporte).
|
|
2. `fn app clone <id>` pueda **arrastrar** los apps-dependencia (o al menos avisarlos).
|
|
3. `fn doctor` detecte clones incompletos (app presente pero su dep ausente).
|
|
|
|
## Propuesta (a concretar)
|
|
|
|
1. **Metadata declarada** en `app.md`: añadir campo `depends_on_apps: [<id>...]`
|
|
en el frontmatter (análogo a `uses_functions`/`uses_types` de las funciones).
|
|
2. **Detección automática** (validación): un audit que parsee los `import` de cada app,
|
|
detecte imports de la forma `fn-registry/apps/<X>/...` o `.../projects/.../apps/<X>/...`
|
|
y compare con `depends_on_apps` (igual que `audit_uses_functions` para funciones).
|
|
- Caso semilla confirmado: `sqlite_api` → `data_factory`.
|
|
3. **`fn app clone --with-deps <id>`**: resuelve el cierre transitivo de `depends_on_apps`
|
|
y clona todo lo necesario a las rutas de `pc_locations`.
|
|
4. **`fn doctor`**: marcar `[incomplete-clone]` si un app está clonado pero falta un
|
|
`depends_on_apps`.
|
|
|
|
## Notas
|
|
|
|
- Relacionado (mismo arrastre de migración, issues aparte si procede):
|
|
- Los `repo_url` de varios apps de servicio (`registry_api`, `services_api`) apuntan al
|
|
alias `gitea.organic-machine.com` que **no resuelve**; el host real es
|
|
`gitea-dgg044oo04woo4ggcsws4gk0.organic-machine.com`. `fn app clone` falla por eso.
|
|
- Los `go.mod` de los apps de servicio requieren `go mod tidy` antes de compilar
|
|
(deps faltantes con go 1.26).
|
|
|
|
## Criterio de hecho
|
|
|
|
- [ ] Campo `depends_on_apps` documentado y poblado al menos en `sqlite_api`.
|
|
- [ ] Audit que detecta imports app→app y reporta drift vs `depends_on_apps`.
|
|
- [ ] `fn app clone` resuelve dependencias (o las avisa).
|