odoo-ls icon indicating copy to clipboard operation
odoo-ls copied to clipboard

Unable to find builtins.pyi

Open ddejong-therp opened this issue 3 months ago • 12 comments

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.

ddejong-therp avatar Sep 18 '25 15:09 ddejong-therp

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 avatar Sep 19 '25 08:09 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

fda-odoo avatar Sep 19 '25 08:09 fda-odoo

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 avatar Sep 19 '25 08:09 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"

ddejong-therp avatar Sep 19 '25 08:09 ddejong-therp

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

fda-odoo avatar Sep 19 '25 09:09 fda-odoo

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 avatar Sep 19 '25 09:09 ddejong-therp

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

ddejong-therp avatar Sep 19 '25 09:09 ddejong-therp

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 avatar Sep 19 '25 10:09 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

fda-odoo avatar Sep 19 '25 10:09 fda-odoo

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 avatar Sep 19 '25 10:09 ddejong-therp

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

ddejong-therp avatar Sep 19 '25 11:09 ddejong-therp

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.

fda-odoo avatar Sep 19 '25 12:09 fda-odoo

I'm not sure if this is the same problem. In my case, it seems to ignore odools.toml completely.

# odools.toml
[[config]]
odoo_path = "./odoo/custom/src/odoo"
stdlib = "./result/lib/python3.13/site-packages/mypy/typeshed/stdlib/"
addons_paths = [
  "./odoo/custom/src/reporting-engine",
  "./odoo/custom/src/stock-logistics-workflow",
  "./odoo/custom/src/server-auth",
  "./odoo/custom/src/design-themes",
  "./odoo/custom/src/sale-workflow",
  "./odoo/custom/src/delivery-carrier",
  "./odoo/custom/src/credit-control",
  "./odoo/custom/src/contract",
  "./odoo/custom/src/private",
  "./odoo/custom/src/mis-builder",
  "./odoo/custom/src/account-financial-tools",
  "./odoo/custom/src/community-data-files",
  "./odoo/custom/src/stock-logistics-warehouse",
  "./odoo/custom/src/queue",
  "./odoo/custom/src/l10n-spain",
  "./odoo/custom/src/account-financial-reporting",
]
# Check required files exist
$ ls ./result/lib/python3.13/site-packages/mypy/typeshed/stdlib/builtins.pyi odools.toml odoo/custom/src/
odools.toml  ./result/lib/python3.13/site-packages/mypy/typeshed/stdlib/builtins.pyi

odoo/custom/src/:
account-financial-reporting  contract          l10n-spain   queue             server-auth
account-financial-tools      credit-control    mis-builder  reporting-engine  server-ux
addons.yaml                  delivery-carrier  odoo         repos.yaml        stock-logistics-warehouse
community-data-files         design-themes     private      sale-workflow     stock-logistics-workflow

# Parse the project
~/.local/share/zed/extensions/work/odoo/1.0.4/odoo_ls_server --parse
2025-12-11T08:58:00.959809Z  INFO odoo_ls_server: >>>>>>>>>>>>>>>>>> New Session <<<<<<<<<<<<<<<<<<
2025-12-11T08:58:00.959822Z  INFO odoo_ls_server: Server version: 1.0.4
2025-12-11T08:58:00.959828Z  INFO odoo_ls_server: Compiled setting: DEBUG_ODOO_BUILDER: false
2025-12-11T08:58:00.959832Z  INFO odoo_ls_server: Compiled setting: DEBUG_MEMORY: false
2025-12-11T08:58:00.959836Z  INFO odoo_ls_server: Compiled setting: DEBUG_THREADS: false
2025-12-11T08:58:00.959840Z  INFO odoo_ls_server: Compiled setting: DEBUG_STEPS: false
2025-12-11T08:58:00.959850Z  INFO odoo_ls_server: Compiled setting: DEBUG_REBUILD_NOW: false
2025-12-11T08:58:00.959854Z  INFO odoo_ls_server: Operating system: linux
2025-12-11T08:58:00.959857Z  INFO odoo_ls_server:
2025-12-11T08:58:00.959862Z  INFO odoo_ls_server: starting server (single parse mode)
2025-12-11T08:58:00.962371Z  INFO odoo_ls_server::cli_backend: Using addons path: []
2025-12-11T08:58:00.962383Z  INFO odoo_ls_server::cli_backend: Using tracked folders: []
2025-12-11T08:58:00.967456Z  INFO odoo_ls_server::core::odoo: Initializing odoo
2025-12-11T08:58:00.967480Z  INFO odoo_ls_server::core::odoo: Full Config: ConfigEntry { name: "default", odoo_path: Some(""), addons_paths: {}, python_path: "python3", additional_stubs: {}, file_cache: true, diag_missing_imports: All, ac_filter_model_names: true, auto_refresh_delay: 1000, stdlib: "", no_typeshed_stubs: false, abstract_: false, diagnostic_settings: {}, diagnostic_filters: [] }
2025-12-11T08:58:00.967501Z  INFO odoo_ls_server::core::odoo: Using stdlib path: /home/yajo/prodevel/moduon-odoo-addons-18/typeshed/stdlib
2025-12-11T08:58:00.967518Z  INFO odoo_ls_server::core::odoo: stub "/home/yajo/prodevel/moduon-odoo-addons-18/typeshed/stubs" - not found
2025-12-11T08:58:00.967525Z  INFO odoo_ls_server::core::odoo: stub "/home/yajo/prodevel/moduon-odoo-addons-18/typeshed/additional_stubs" - not found
2025-12-11T08:58:00.967534Z  INFO odoo_ls_server::core::entry_point: Adding new builtins entry point: /home/yajo/prodevel/moduon-odoo-addons-18/typeshed/stdlib
2025-12-11T08:58:00.967578Z  INFO odoo_ls_server::core::entry_point: Adding new public entry point: /home/yajo/prodevel/moduon-odoo-addons-18/typeshed/stubs
2025-12-11T08:58:00.967600Z  INFO odoo_ls_server::core::entry_point: Adding new public entry point: /home/yajo/prodevel/moduon-odoo-addons-18/typeshed/additional_stubs
2025-12-11T08:58:00.984263Z  INFO odoo_ls_server::core::entry_point: Adding new public entry point: /nix/store/3lll9y925zz9393sa59h653xik66srjb-python3-3.13.9/lib/python3.13
2025-12-11T08:58:00.984319Z  INFO odoo_ls_server::core::entry_point: Adding new public entry point: /nix/store/3lll9y925zz9393sa59h653xik66srjb-python3-3.13.9/lib/python3.13/lib-dynload
2025-12-11T08:58:00.984338Z  INFO odoo_ls_server::core::entry_point: Adding new public entry point: /nix/store/3lll9y925zz9393sa59h653xik66srjb-python3-3.13.9/lib/python3.13/site-packages
2025-12-11T08:58:00.999442Z  INFO odoo_ls_server::core::odoo: Detected python version: 3.13.9
2025-12-11T08:58:00.999465Z ERROR odoo_ls_server::core::odoo: Unable to find builtins at: /home/yajo/prodevel/moduon-odoo-addons-18/typeshed/stdlib/builtins.pyi
2025-12-11T08:58:00.999503Z ERROR odoo_ls_server::cli_backend: not handled method: $Odoo/loadingStatusUpdate
2025-12-11T08:58:00.999516Z ERROR odoo_ls_server::cli_backend: not handled method: $Odoo/loadingStatusUpdate
2025-12-11T08:58:00.999552Z  INFO odoo_ls_server: >>>>>>>>>>>>>>>>>> End Session <<<<<<<<<<<<<<<<<<

According to the logs, not only it's ignoring the stdlib I passed in the config file. It's ignoring everything inside the config file.

yajo avatar Dec 11 '25 08:12 yajo

@yajo

Hello!

Thank you for reaching out.

Indeed, it is not the same issue, in your case you are running odools in CLI (parse) mode. In this case you shall use the cli arguments. Currently the odools.toml is used when in in LSP mode. ( I will add it to our agenda to be able to use odools.toml in CLI mode and just pass --config-path, but currently that is not supported)

To get some help on the arguments you could run, odoo_ls_server --help.

For your config we would have something like this more or less:

~/.local/share/zed/extensions/work/odoo/1.0.4/odoo_ls_server\
  --parse  \
  --stdlib ./result/lib/python3.13/site-packages/mypy/typeshed/stdlib \
  --community-path "./odoo/custom/src/odoo" \
  --tracked-folders "./odoo/custom/src" \
  -a "./odoo/custom/src/reporting-engine" \
  -a "./odoo/custom/src/stock-logistics-workflow" \
  -a "./odoo/custom/src/server-auth" \
  -a "./odoo/custom/src/design-themes" \
  -a "./odoo/custom/src/sale-workflow" \
  -a "./odoo/custom/src/delivery-carrier" \
  -a "./odoo/custom/src/credit-control" \
  -a "./odoo/custom/src/contract" \
  -a "./odoo/custom/src/private" \
  -a "./odoo/custom/src/mis-builder" \
  -a "./odoo/custom/src/account-financial-tools" \
  -a "./odoo/custom/src/community-data-files" \
  -a "./odoo/custom/src/stock-logistics-warehouse" \
  -a "./odoo/custom/src/queue" \
  -a "./odoo/custom/src/l10n-spain"

Let me know if it all works well, looking forward to hearing back from you

mmahrouss avatar Dec 11 '25 14:12 mmahrouss

I was trying to understand why the Zed extension didn't work, but if the CLI works differently, then that's unfortunate. Now I can't diagnose it 😕

Indeed that command seems to return something more meaningful.

yajo avatar Dec 12 '25 08:12 yajo