At LTC Labs we like asking the same question to several models and seeing what they answer. This time the question came straight out of the real work we have been covering on the blog these days, and it has a trap.
Working on our deployment orchestrator we ran into a very specific Odoo question: in a module's __manifest__.py you declare dependencies on other modules (depends) and Python libraries (external_dependencies['python']). But what if the module needs software installed with apt, or code from a GitHub repository that is not on pip? Can you declare that in the manifest? That was, word for word, the question we put to nine models.
The ground truth (verified today in the Odoo 16 source, odoo/modules/module.py, function check_manifest_dependencies):
external_dependencieshas exactly two subkeys that Odoo checks:pythonandbin. Nothing more.python: Odoo triespkg_resources.get_distribution()first (the PyPI distribution name, the pip one) and only falls back toimportfor backward compatibility. The recommended value is the pip name.bin: checks that the executable exists on thePATH(find_in_path). Nothing more.- There is no
deb,aptor GitHub key. The manifest only verifies as a precondition; it never installs. apt and GitHub are resolved outside Odoo (Dockerfile, Ansible, deployment scripts): you install the software in the image and declare the binary inbin, or you runpip install git+https://...and declare the name inpython.
With that yardstick we read the nine answers. For each model: its name, its screenshots, and our comment.
GLM 5.2
Correct
Our comment: A complete answer: it nails the two real subkeys, invents no apt/deb key, and answers exactly what was asked (apt via bin plus external provisioning, and GitHub via pip git+https or a compiled binary). It makes clear the point people most often get wrong: the manifest verifies, it does not install, and it never carries a GitHub URL. The only nit is the source function name, which it made up; the mechanism, though, is flawless.
Gemini
Mostly correct
Our comment: A good answer: it gets the essentials right (there is no apt/deb or git key in the manifest, bin only verifies, and the actual install happens at deploy time, with requirements and git+https or git-aggregator). The Odoo.sh paragraph grates on us: it claims the platform auto-installs apt packages from the manifest's bin key, and that does not happen; bin never installs anything. It is also imprecise in selling python as the import name when Odoo prioritizes the PyPI distribution name. With those two nits fixed it would be a complete answer.
DeepSeek V4 Flash Free (high)
Mostly correct
Our comment: We like it: it is the most concise, no-filler answer of the bunch. It nails the essentials: there is only python and bin, the manifest verifies but never installs, and apt or git go into the Dockerfile or deployment scripts, not the manifest. It overreaches with the Odoo 18 and PEP 508 aside (unverified and out of context) and lacks rigor when it calls the python subkey an 'import check', when Odoo tries the PyPI name first. With those two nits, a strong grade.
Nemotron 3 Ultra Free (high)
Correct
Our comment: A solid, no-nonsense answer. It gets right what sinks other models: it invents no apt/deb/system key and makes clear that the manifest only verifies, never installs, pushing installation to the pipeline (Docker, Ansible, CI). The only nit is cosmetic: it paints python as an importability check when Odoo actually tries the PyPI distribution name first. For us, a pass.
MiMo V2.5 Free (high)
Correct
Our comment: A solid, no-nonsense answer. It nails the essentials: there is only python and bin, bin only verifies the PATH, and neither apt nor GitHub exist as a manifest key, with a table that spells it out in black and white. It missed the get_distribution versus import nuance in python, but since it couples nothing false and invents no apt key, for us this is correct.
Opus 4.8
Mostly correct
Our comment: We like this answer: it gets to the point, denies the myth of an apt or git key in the manifest, and invents no 'deb', 'system' or 'packages', which was the trap. It nails the verify-not-install point and the correct split (bin plus Dockerfile, python plus requirements with git). The only nit is the classic one: it says python is the import name and not the pip one, when Odoo 16 tries the PyPI distribution name first. A minor slip on an answer that is otherwise among the best.
Big Pickle
Partially correct
Our comment: Big Pickle nails the underlying idea (the manifest verifies, never installs; apt and GitHub go outside Odoo) and its four routes for pulling in GitHub code are reasonable. But it invents two keys that do not exist, 'deb' with dpkg and 'rpm' with rpm, and sells them as native Odoo 15+ functionality: the 16 core only looks at python and bin, full stop. It is a dangerous hallucination because it sounds plausible and even contradicts its own closing. Right on the thesis, a fail on the technical detail.
Hy3 Free (high)
Mostly correct
Our comment: A solid, direct answer: it gets the essentials right (only python and bin; the manifest validates, does not install; apt via bin, GitHub-python via requirements or Dockerfile, and the rest outside the manifest) and falls into no apt/deb key hallucination or magic install. We would give it a single nit: it reduces the python check to an 'import', when Odoo 16 tries get_distribution (the PyPI name) first, which is the recommended one. A minor detail that does not affect practical usefulness; it works for us.
North Mini Code Free (high)
Mostly correct
Our comment: It hits the bullseye on the essentials: only python and bin, zero apt key, and provisioning outside Odoo. We like that it does not invent the 'deb' key that other models hallucinate. But it stays on the surface: it does not get down to the useful recipe (git+https in the Dockerfile plus the name in python, or a binary plus bin) and on top of that it slips in a phantom __setup__.py and some post-install hooks that do not install apt. Right in concept, weak in practical execution.
Did any of them hallucinate?
Yes, and this is where the wheat separates from the chaff. Nobody missed the core thesis (they all understood that the manifest does not install), but several invented mechanisms that do not exist:
- Big Pickle is the worst case: it invented two manifest keys that do not exist,
deb(which it claimed Odoo would check withdpkg) andrpm(withrpm), and sold them as native Odoo 15+ functionality. The Odoo 16 core only looks atpythonandbin; any other key is silently ignored. It is the most dangerous hallucination because it sounds plausible and even contradicts its own summary. - North Mini Code invented a
__setup__.pyto install apt packages and some post-install hooks that would install system software. No such thing exists: the hooks run inside the ORM, without root privileges. - Gemini claimed that Odoo.sh auto-installs apt packages from the
binkey. It does not:binonly checks that the binary is on the PATH. - DeepSeek V4 Flash slipped in a remark about Odoo 18 and PEP 508 version specifiers (
ocrmypdf>=15) that is beside the point and that it did not verify. - And one slip shared by almost all of them, Opus 4.8 included: describing
pythonas "the import name" when Odoo prioritizes the PyPI distribution name (the pip one). The import name works, but by backward compatibility, not by design.
The table, at a glance
| Model | Verdict | Main hallucination |
|---|---|---|
| GLM 5.2 | Correct | Wrong source function name cited (minor) |
| Gemini | Mostly correct | Odoo.sh auto-installs apt (false); python=import |
| DeepSeek V4 Flash Free (high) | Mostly correct | Invents PEP 508 in Odoo 18; python=import |
| Nemotron 3 Ultra Free (high) | Correct | python=importable (nuance) |
| MiMo V2.5 Free (high) | Correct | None |
| Opus 4.8 | Mostly correct | python=import name, not pip (inverted) |
| Big Pickle | Partially correct | Invents native deb (dpkg) and rpm keys |
| Hy3 Free (high) | Mostly correct | python=import (nuance) |
| North Mini Code Free (high) | Mostly correct | Invents __setup__.py for apt (false) |
Our conclusion
The most interesting part is not who won, but how. The brand names did not sweep the board: several "free" models nailed the core, and the one that invented two nonexistent keys was one of them. Not even the strongest answer escaped the get_distribution versus import nuance. When the right answer is "you cannot do that in the manifest, you have to solve it outside", the good model is the one that does not fill the gap with an invented key.
If we had to pick one: MiMo V2.5, the only one with zero hallucinations and a table that makes it black and white that there is no apt or GitHub key. Close behind, GLM 5.2 and Nemotron 3 Ultra, for being concise and inventing nothing. Opus 4.8 gave one of the best-structured answers, with its only slip being the classic python=import.
And you, which answer looks "best" to you? Tell us.
-- Fer & Claude, LTC Labs