-
Notifications
You must be signed in to change notification settings - Fork 26.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mason setup is called twice #1297
Comments
Nice catch. @tomasgareau make a PR but put mason setup outside the dependencies table ie keep the second setup call and make the mason dependency a string. Additionally, I would move the NOTE to the second setup call. |
I agree that using However, your original approach is correct. I was hesitant because I thought it might affect readability, but as long as the setup is properly explained and the comments from the second setup call are incorporated, it should work well. |
Addresses nvim-lua#1297 Currently, we're calling `require('mason').setup(...)` twice: * once when setting it as a dependency of `nvim-lspconfig` (since we set `config = true`) * once in the `config` function we define for `nvim-lspconfig` Calling setup twice can cause issues with, e.g., setting the `PATH` option: you might append Mason's bin dir in one setup call and prepend it in the other. We've kept the setup of `mason` in the `nvim-lspconfig` dependencies table since leaving it to the `config` function caused some plugin-loading-order related issues in the past. See: * nvim-lua#210 * nvim-lua#554 * nvim-lua#555 * nvim-lua#865
When setting up
nvim-lspconfig
, we tell Lazy thatmason.nvim
is a dependency and configure it right away (#865 & linked issues touch on why):kickstart.nvim/init.lua
Lines 456 to 460 in a8f5395
But later in
nvim-lspconfig
'sconfig
function, we explicitly setupmason
again:kickstart.nvim/init.lua
Lines 648 to 654 in a8f5395
These two setup calls can interfere with each other. For example, if you tweaked the second setup call to append Mason's bin path (e.g., to allow overriding Mason binaries with system binaries):
the first setup call will prepend the Mason bin path (the default behaviour) and your change will append the bin path. Your path then ends up being:
Oops haha.
I think we can just bin the second
setup
call and put all the mason configuration in thedependencies
block:(but I'm not sure if e.g., the second setup call is required for auto-installation after the other config). Happy to toss up a PR if the above makes sense!
The text was updated successfully, but these errors were encountered: