En LTC Labs nos gusta hacer la misma pregunta a varios modelos y ver qué contestan. Esta vez la pregunta salió del trabajo real que contamos estos días en el blog, y tiene trampa.
Trabajando en nuestro orquestador de despliegues nos topamos con una duda muy concreta de Odoo: en el __manifest__.py de un módulo se declaran las dependencias de otros módulos (depends) y las librerías de Python (external_dependencies['python']). Pero, ¿y si el módulo necesita software que se instala con apt, o código de un repositorio de GitHub que no está en pip? ¿Se puede declarar eso en el manifest? Esa fue, palabra por palabra, la pregunta que le hicimos a nueve modelos.
La verdad de referencia (verificada hoy en el código fuente de Odoo 16, odoo/modules/module.py, función check_manifest_dependencies):
external_dependenciestiene exactamente dos subclaves que Odoo comprueba:pythonybin. No hay más.python: Odoo intenta primeropkg_resources.get_distribution()(el nombre de distribución de PyPI, el de pip) y solo cae aimportpor retrocompatibilidad. Lo recomendado es el nombre de pip.bin: comprueba que el ejecutable exista en elPATH(find_in_path). Nada más.- No existe ninguna clave
deb,aptni de GitHub. El manifest solo verifica como precondición; nunca instala. El apt y el GitHub se resuelven fuera de Odoo (Dockerfile, Ansible, scripts de despliegue): instalas el software en la imagen y declaras el binario enbin, o hacespip install git+https://...y declaras el nombre enpython.
Con esa vara de medir leímos las nueve respuestas. Por cada modelo: su nombre, sus capturas, y nuestro comentario.
GLM 5.2
Correcto
Nuestro comentario: Respuesta redonda: clava las dos subclaves reales, no se inventa ninguna clave apt/deb y contesta exactamente lo que se preguntaba (apt vía bin más aprovisionamiento externo, y GitHub vía pip git+https o binario compilado). Deja claro el punto que más se suele fallar: el manifest verifica, no instala, y nunca lleva una URL de GitHub. El único pero es el nombre de la función fuente, que se lo sacó de la manga; el mecanismo, en cambio, es impecable.
Gemini
Mayormente correcto
Nuestro comentario: Buena respuesta: acierta en lo esencial (no hay clave apt/deb ni git en el manifest, bin solo verifica y la instalación real va en el despliegue, con requirements y git+https o git-aggregator). Nos chirría el párrafo de Odoo.sh: afirma que la plataforma auto-instala paquetes apt a partir del bin del manifest, y eso no ocurre; bin nunca instala nada. También peca de imprecisa al vender python como nombre de import cuando Odoo prioriza el nombre de distribución de PyPI. Con esos dos matices corregidos sería una respuesta redonda.
DeepSeek V4 Flash Free (high)
Mayormente correcto
Nuestro comentario: Nos gusta: es la respuesta más concisa y sin paja de la tanda. Clava lo esencial: solo hay python y bin, el manifest verifica pero nunca instala, y el apt o el git van al Dockerfile o a scripts de despliegue, no al manifest. Le sobra la coletilla de Odoo 18 y PEP 508 (sin verificar y fuera de contexto) y le falta rigor al llamar 'check de import' a la subclave python, cuando Odoo tira primero del nombre de PyPI. Con esos dos matices, un notable alto.
Nemotron 3 Ultra Free (high)
Correcto
Nuestro comentario: Respuesta sólida y sin humo. Acierta en lo que hunde a otros modelos: no se inventa ninguna clave apt/deb/system y deja claro que el manifest solo verifica, nunca instala, empujando la instalación al pipeline (Docker, Ansible, CI). El único pero es cosmético: pinta python como chequeo de importabilidad cuando en realidad Odoo prueba primero el nombre de distribución de PyPI. Para nosotros, aprobado.
MiMo V2.5 Free (high)
Correcto
Nuestro comentario: Respuesta sólida y sin humo. Clava lo esencial: solo hay python y bin, bin únicamente verifica el PATH, y ni apt ni GitHub existen como clave del manifest, con una tabla que lo deja negro sobre blanco. Le faltó el matiz de get_distribution frente a import en python, pero como no acopla nada falso ni inventa claves apt, para nosotros esto es correcto.
Opus 4.8
Mayormente correcto
Nuestro comentario: Nos gusta esta respuesta: va al grano, niega el mito de la clave apt o git en el manifest y no se inventa 'deb', 'system' ni 'packages', que era la trampa. Clava el verifica-no-instala y el reparto correcto (bin más Dockerfile, python más requirements con git). El único pero es el clásico: dice que python es el nombre de import y no el de pip, cuando Odoo 16 prueba antes el nombre de distribución de PyPI. Un desliz menor sobre una respuesta que, por lo demás, es de las mejores.
Big Pickle
Parcialmente correcto
Nuestro comentario: Big Pickle clava la idea de fondo (el manifest verifica, nunca instala; apt y GitHub van fuera de Odoo) y las cuatro rutas para meter código de GitHub son razonables. Pero se inventa dos claves que no existen, 'deb' con dpkg y 'rpm' con rpm, y las vende como funcionalidad nativa de Odoo 15+: el core de la 16 solo mira python y bin, punto. Es una alucinación peligrosa porque suena verosímil y hasta contradice su propio cierre. Correcto en la tesis, suspenso en la ficha técnica.
Hy3 Free (high)
Mayormente correcto
Nuestro comentario: Respuesta sólida y directa: acierta en lo esencial (solo python y bin; el manifest valida, no instala; apt vía bin, GitHub-python vía requirements o Dockerfile, y el resto fuera del manifest) y no cae en ninguna alucinación de clave apt/deb ni de instalación mágica. Le pondríamos una sola pega: reduce la comprobación de python a un 'import', cuando Odoo 16 prueba antes get_distribution (el nombre de PyPI), que es el recomendado. Detalle menor que no afecta a la utilidad práctica; nos vale.
North Mini Code Free (high)
Mayormente correcto
Nuestro comentario: Da en la diana de lo esencial: solo python y bin, cero clave apt, y aprovisionamiento fuera de Odoo. Nos gusta que no se invente la clave 'deb' que otros modelos alucinan. Pero se queda en la superficie: no baja a la receta útil (git+https en el Dockerfile más el nombre en python, o binario más bin) y encima cuela un __setup__.py fantasma y unos post-install hooks que no instalan apt. Correcto de concepto, flojo de ejecución práctica.
¿Alucinó alguno?
Sí, y aquí es donde se separa el grano de la paja. Nadie falló la tesis de fondo (todos entendieron que el manifest no instala), pero varios se inventaron mecanismos que no existen:
- Big Pickle es el caso más grave: se inventó dos claves de manifest que no existen,
deb(que según él Odoo comprobaría condpkg) yrpm(conrpm), y las vendió como funcionalidad nativa de Odoo 15+. El core de Odoo 16 solo mirapythonybin; cualquier otra clave la ignora en silencio. Es la alucinación más peligrosa porque suena verosímil y hasta contradice su propio resumen. - North Mini Code se inventó un
__setup__.pypara instalar paquetes apt y unos post-install hooks que instalarían software del sistema. No existe tal cosa: los hooks corren dentro del ORM, sin privilegios de root. - Gemini afirmó que Odoo.sh auto-instala paquetes apt a partir de la clave
bin. No lo hace:binsolo verifica que el binario esté en el PATH. - DeepSeek V4 Flash coló una coletilla sobre Odoo 18 y especificadores de versión PEP 508 (
ocrmypdf>=15) que no viene al caso y que no verificó. - Y un desliz compartido por casi todos, incluido Opus 4.8: describir
pythoncomo "el nombre de import" cuando Odoo prioriza el nombre de distribución de PyPI (el de pip). El de import funciona, pero por retrocompatibilidad, no por diseño.
La tabla, de un vistazo
| Modelo | Veredicto | Alucinación principal |
|---|---|---|
| GLM 5.2 | Correcto | Nombre de función mal citado (menor) |
| Gemini | Mayormente correcto | Odoo.sh auto-instala apt (falso); python=import |
| DeepSeek V4 Flash Free (high) | Mayormente correcto | Inventa PEP 508 en Odoo 18; python=import |
| Nemotron 3 Ultra Free (high) | Correcto | python=importable (matiz) |
| MiMo V2.5 Free (high) | Correcto | Ninguna |
| Opus 4.8 | Mayormente correcto | python=nombre de import, no de pip (invertido) |
| Big Pickle | Parcialmente correcto | Inventa claves deb (dpkg) y rpm nativas |
| Hy3 Free (high) | Mayormente correcto | python=import (matiz) |
| North Mini Code Free (high) | Mayormente correcto | Inventa __setup__.py para apt (falso) |
Nuestra conclusión
Lo más interesante no es quién ganó, sino cómo. Los nombres de marca no arrasaron: varios modelos "free" clavaron el núcleo, y el que se inventó dos claves inexistentes fue uno de ellos. Ni la respuesta más sólida se libró del matiz de get_distribution frente a import. Cuando la pregunta correcta es "eso no se puede hacer en el manifest, hay que resolverlo fuera", el modelo bueno es el que no rellena el hueco con una clave inventada.
Si tuviéramos que quedarnos con una: MiMo V2.5, la única con cero alucinaciones y una tabla que deja negro sobre blanco que no existe clave apt ni de GitHub. Pegadas, GLM 5.2 y Nemotron 3 Ultra, por concisas y por no inventarse nada. Opus 4.8 dio de las respuestas mejor estructuradas, con su único pero en el clásico python=import.
Y a vosotros, ¿qué respuesta os parece "mejor"? Contádnoslo.
-- Fer & Claude, LTC Labs