fn_registry/functions/infra/resolve_registry_root.md

name, kind, lang, domain, version, purity, signature, description, tags, uses_functions, uses_types, params, output, returns, returns_optional, error_type, imports, tested, tests, test_file_path, file_path

name	kind	lang	domain	version	purity	signature	description	tags	uses_functions	uses_types	params	output	returns	returns_optional	error_type	imports	tested	tests	test_file_path	file_path
resolve_registry_root	function	go	infra	1.0.0	impure	func ResolveRegistryRoot() (string, error)	Devuelve la ruta absoluta de la raíz del fn_registry (el directorio que contiene registry.db). Resuelve en orden: env var FN_REGISTRY_ROOT, walk-up desde el ejecutable (hasta 6 niveles), y $HOME/fn_registry. Retorna error si ningún método localiza registry.db. Centraliza la resolución dinámica para que ningún binario del ecosistema necesite un path hardcodeado.	registry infra root path env			name desc (ninguno) La función no recibe argumentos.	Ruta absoluta del directorio raíz del fn_registry (contiene registry.db), o error descriptivo si no se encontró.		false	error_go_core	fmt os path/filepath	true	env var apunta a tmpdir con registry.db HOME apunta a tmpdir con fn_registry/registry.db nada existe devuelve error	functions/infra/resolve_registry_root_test.go	functions/infra/resolve_registry_root.go

Ejemplo

root, err := infra.ResolveRegistryRoot()
if err != nil {
    log.Fatalf("no se pudo localizar fn_registry: %v", err)
}
// Construir ruta al binario fn
fnBin := filepath.Join(root, "fn")
cmd := exec.Command(fnBin, "run", "mi_funcion")

Cuando usarla

Cuando un binario Go del ecosistema (dag_engine, deploy_server, registry_mcp, etc.) necesita localizar la raíz del registry para construir rutas a fn run, abrir registry.db, o encontrar python/.venv — y FN_REGISTRY_ROOT puede no estar seteado en el entorno del usuario.

Gotchas

• Depende del entorno en tiempo de ejecución (env vars + filesystem): no es determinista. Dos llamadas sucesivas desde entornos distintos pueden devolver rutas distintas.
• El paso 2 (walk-up desde ejecutable) asume que el binario vive dentro del árbol del registry. Si el binario se copia a /usr/local/bin o a un directorio externo, este paso no encontrará nada — los pasos 1 y 3 sirven como fallback.
• En go test el exe es un binario temporal generado por el framework de tests, que vive en /tmp/. Por eso el paso 2 no encontrará registry.db durante los tests unitarios. Los tests de esta función usan t.Setenv para cubrir los pasos 1 y 3 sin depender del entorno real.
• El paso 3 deriva $HOME dinámicamente con os.UserHomeDir() — nunca hay paths de usuario hardcodeados.