Unable to find builtins.pyi

[ddejong-therp]

Your setup
Version: 1.0.1
Operating System: NixOS 25.05
IDE and/or Integration tool: Neovim 0.11.1

Describe the bug
A clear and concise description of what the bug is.
When odoo-ls starts, it gives me this error message in the log:
[ERROR][2025-09-18 17:20:11] ...lsp/handlers.lua:562 "Unable to find builtins.pyi. Are you sure that typeshed has been downloaded. If you are building from source, make sure to initialize submodules with 'git submodule init' and 'git submodule update'."

To Reproduce
Steps to reproduce the behavior:
Put this config in neovim's lsp folder of the runtime folder:

local lsp_dir = vim.fs.abspath('~/lsp')
local code_dir = vim.fs.abspath('~/code')

local server_dir = lsp_dir .. '/odoo-ls/server'
-- Get the default client capabilities
local capabilities = vim.lsp.protocol.make_client_capabilities()

-- Add your custom capability
capabilities.general.markdown = {
  parser = 'marked',
  version = ""
}
return {
  cmd = {
    server_dir .. '/target/release/odoo_ls_server',
    '--stdlib',
    server_dir .. '/typeshed/stdlib'
  },
  root_dir = server_dir .. '/target/release',
  filetypes = { 'python' },
  workspace_folders = {{
      uri = vim.uri_from_fname(code_dir),
      name = 'main_folder',
  }},
  capabilities = capabilities,
}

I've build odoo-ls from source at ~/lsp/odoo-ls/server, with the rust toolchain 1.90.0.

Expected behavior
I expect odoo-ls to not give me this error upon loading the language server. Perhaps, for it to work already with the above configuration.

Additional context
I have debugged a little bit what path is being searched for builtins.pyi, it turns out it used the current working directory I open Neovim in. So the file is basically being searched in {working-dir}/typeshed/stdlib/builtins.pyi.
I've left out the real path because it contains a customer's company name.

[fda-odoo]

When you are building from source or downloading manually as you did, you have to clone the typeshed repository alongside odoo_ls_server. The documentation is indeed missing this information at some places.
By default, odoo_ls_server is searching for a typeshed folder next to him or in the working_dir directory. However here you provided a custom path in your configuration with

    server_dir .. '/typeshed/stdlib'" 

so be sure that typeshed is available at this place. you can clone typeshed from https://github.com/python/typeshed

[fda-odoo]

if you did the git submodule init and update in your source code already, typeshed should already have been downloaded in server/typeshed too

[ddejong-therp]

The typeshed submodule was already available when building, and the file(s) are actually in there. I cloned with the --recurse-submodules flag and of course I checked if the submodule was checked out by hand.

My point is that the path I give to the --stdlib variable exists, and for some reason I still get the above error.
Here is my cmd field for the lsp configuration within neovim that I can see with :checkhealth:
cmd: { "/home/therp/lsp/odoo-ls/server/target/release/odoo_ls_server", "--stdlib", "/home/therp/lsp/odoo-ls/server/typeshed/stdlib" }
And I have verified that builtins.pyi is in /home/therp/lsp/odoo-ls/server/typeshed/stdlib

[ddejong-therp]

So when I look a the code, it seems it is looking for the typeshed/stdlib directory next to the executable file, or in the current working directory: https://github.com/odoo/odoo-ls/blob/1.0.1/server/src/core/odoo.rs#L160

So I'm guessing that the command line argument --stdlib is not being honored.

I tried copying the odoo_ls_server executable to the same dir typeshed lives in, and have neovim execute it from there,
but then I get this:

[ERROR][2025-09-19 10:57:16] ...p/_transport.lua:36     "rpc"   "/home/therp/lsp/odoo-ls/server/odoo_ls_server" "stderr"              "Error waiting for process 34747: ECHILD: No child processes\n"

[fda-odoo]

You're right, I see that some options are not available in command line right now, because the configuration (even empty) coming from files is overriding it (except in parse mode, that you are not using).
It means that until the next update, you'll have to either:

• provide typeshed next to the executable or,
• provide typeshed in your working directory or,
• provide typeshed anywhere you want, but then create an odools.toml file that is giving the right path to the typeshed directory with

[[config]]
name = "My Config"
odoo_path = "/home/odoo/community"
stdlib = "/home/odoo/typeshed/stdlib/"

do not forget the ending '/' that is mandatory here for folders

[ddejong-therp]

Thank you, I've gone the route of putting the executable next to the typeshed dir.

Now I have another error but I have a feeling it has to do with the fact that I haven't configured odoo-ls yet to have an odoo path and addons path.
I'm going to configure that soon.

[ddejong-therp]

Can I use the command-line flags --config-path and --addons instead of the odools.toml file?

[fda-odoo]

You can use --config-path to provide a configuration file, but this configuration has to be an odools.toml. this setting is there to let you put it where you want instead of the project folder or above
however --addons will not work because this argument is not taken into account in "language server" mode, we will fix that in next version

[fda-odoo]

The error "error waiting for process" is normal in your case though, and it should not be blocking.
Are you sure your server is crashing? This error should only be a log you can ignore. OdooLS can take 10-20 seconds to start, depending on your machine, maybe it was not already ready when you tried to use it?
Next to your odoo_ls_server you should have a logs folder that can maybe be interesting

[ddejong-therp]

Well, I'm not sure if it was because I started playing with the --addons-path and --config-path parameters, but I have been able to start odoo-ls now, and it is giving me warnings about odoo modules not existing now :D
EDIT: So great, I guess I'm almost there!

I think the next step would be to make sure odoo-ls knows about where odoo is.
So if --config-path is not about the odoo.cfg file but about the odools.toml file, I guess I need to try something else.
I prefer to not have to create an additional file (odools.toml) so that odoo-ls also works in projects where no such file is present.
I'm guessing I could try to set the workspace directory to the directory that I know contains the odoo repo dir.
But in my case that is not the same dir that contains the addons I'm working on.
EDIT: I worry that if odoo-ls is going to look for the odoo dir in the workspace dir, it is going to look for the addons in the workspace only as well. But I experiment and see if it works that way or not.

If I can't get around having to create a odools.toml file for my workflow, I might think about automatically generating it every time I run odoo-ls.

[ddejong-therp]

@fda-odoo But you might also be right, maybe it was already working and I didn't notice it ^^

[fda-odoo]

If you don't want to use odools.toml files, the default profile will be used, and so it will try to detect odoo and addons automatically.

To get it work easily, odoo (with odoo-bin in the folder) should be a root of your workspace. To add additional addons to odoo, as enterprise, you should add them as root of your workspace (and so use mutli-root workspace).
By doing that, OdooLS should be able to detect odoo and add as many addons as you want. That's not really flexible, but if you want more flexibility, you'll have to use odools.toml files unfortunately. In these files, you can define multiple profiles, extend them, define them with dynamic paths, etc...
For example, you could open only your custom module in your editor, and have a global profile that take an odoo path at a relative path, or based on a detected version for example.