Skip to content
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

Document configuration from lsp #32

Open
Ae-Mc opened this issue Jan 21, 2022 · 10 comments
Open

Document configuration from lsp #32

Ae-Mc opened this issue Jan 21, 2022 · 10 comments
Milestone

Comments

@Ae-Mc
Copy link

Ae-Mc commented Jan 21, 2022

Support configuration passed via didChangeDependencies method of LSP protocol.

UPD: And add information about it to documentation.

@Richardk2n Richardk2n added this to the 0.7.0 milestone Jul 18, 2022
@doolio
Copy link

doolio commented Sep 16, 2022

Don't you mean via didChangeConfiguration?

@Ae-Mc
Copy link
Author

Ae-Mc commented Sep 21, 2022

Yes, sorry, didChangeDependencies is method from Flutter. didChangeConfiguration is the right name of the LSP protocol's method.

@Richardk2n
Copy link
Member

All but one options passed this way should work I think, depending on when the config gets updated, or is there a specific hook you want me to implement?

@kbvw
Copy link

kbvw commented Jan 31, 2023

Hi,

A bit more specific but related to the original question: I'm currently using eglot, python-lsp and pylsp-mypy. For the built-in pylsp plugins, they can be configured according to the options listed here. I set those with the eglot-workspace-configuration directory-local variable, as explained here in section 3.4, which eglot then passes to the server. (Notably, I set the Python virtual environment with this.)

Is there a way to set pylsp-mypy options in the same place? Perhaps this is already possible, but I'm not sure how: I played around with throwing them in there, but no luck.

As an alternative: would it be possible for pylsp-mypy to read a hidden configuration file, like .pylsp-mypy.ini or .pylsp-mypy.cfg? Mypy itself reads a hidden .mypy.ini file for example. (I can set the Python environment and other mypy options there, I would just like to control dmypy and live_mode as well for the plugin.)

I set these options in a directory containing a virtual environment and multiple repositories for which I use the same virtual environment, hence my wish to drop one or otherwise a few hidden config files in that directory and have everything configured for these repositories together. The current (visible) pylsp-mypy.cfg works; I'm just trying to avoid having many different (visible) config files.

Thanks a lot!

@doolio
Copy link

doolio commented Jan 31, 2023

@kbvw I presume you are using a .dir-locals.el file with Eglot? Here is a complete one for the pylsp server. It does not include any pylsp-mypy settings (as it is not a built-in plugin) but you could try adding the following below the :pylint section. I'd be interested to know if that works for you.

                                                 :pylsp_mypy
                                                 (:config_sub_paths [] ; string array: [] (default)
                                                                    :dmypy :json-false ; boolean: true or false (default)
                                                                    :dmypy_status_file "dmypy.json" ; string: "dmypy.json" (default)
                                                                    :live_mode t ; boolean: true (default) or false
                                                                    :overrides [True] ; string-array: [True] (default)
                                                                    :report_progress :json-false ; boolean: true or false (default)
                                                                    :strict :json-false) ; boolean: true or false (default)

@kbvw
Copy link

kbvw commented Feb 1, 2023

@doolio Works like a charm. That's really helpful; many thanks!

(Indeed I'm setting them in a .dir-locals.el.)

On the original issue: it would be helpful if this route of configuration (from the client) is in the readme, since the functionality seems to be there. I guess all you need to know is A: that it's indeed possible, and B: that you have to supply the options under plugins and then pylsp_mypy with the underscore. In hindsight I could have guessed it (being Python) and it's clear from the source, but hindsight is hindsight. :)

On the general config issue: maybe it could be unified a somewhat between the plugin and the server? For this plugin, it supports a legacy pylsp-mypy.cfg and pyproject.toml, the latter being preferred. And then you can pass options from the client, but it's not completely clear how. The server supports individual configs for the built-in plugins, and setup.cfg, but seemingly not pyproject.toml. They document what options you can set from the client, but not for the third-party plugins. Takes a bit of time to figure out how to set all options in one place.

Thanks again, it works well for me now!

@doolio
Copy link

doolio commented Feb 1, 2023

Glad to hear it.

I agree with having a single configuration source for all these plugins. It probably makes sense for pylsp to adopt pyproject.toml to that end as that seems to be becoming the standard and ditch support for all other config files. It also pushes the config onto the server (and its plugins) rather than the client which arguably makes more sense as it is the server that is common to all and not the client which comes down to user preference.

@sykloid
Copy link

sykloid commented Nov 1, 2023

I'm not sure if necro'ing this thread is the best idea, but I'm trying to get almost exactly the same thing to work, and I'm not sure what I'm doing wrong, or if the best practices have changed in the year or so since this thread was posted.

Here's my .dir-locals.el:

((python-mode
  . ((eglot-workspace-configuration
      . (:pylsp (:plugins
                 (:jedi (:environment ".venv/bin/python"))
                  :pylsp_mypy (:overrides ["--python-executable" ".venv/bin/python" "True"])))))))

I'm pretty sure that the :jedi :environment interpreter path is being parsed and respected, but the :overrides are definitely not. Am I doing something obviously incorrect?

I'm also not sure if pyproject.toml-based configuration is the way to go for some options, since I wouldn't want to be checking in local paths to venv interpreters. Any suggestions on how you guys are working around that?

@doolio
Copy link

doolio commented Nov 1, 2023

@sykloid I think you have too many parentheses. Can you try this snippet instead?

((python-mode
  . ((eglot-workspace-configuration
      . (:pylsp (:plugins
                 (:jedi
                  (:environment ".venv/bin/python") ; string: null (default)
                  :pylsp_mypy
                  (:overrides ["--python-executable" ".venv/bin/python" True])))))))) ; string-array: [True] (default)

Edit: Note, I don't believe True should be a string as you had it.

Curious why you don't (or do you?) include all the possible settings in your .dir-locals.el file? I linked to a complete (for the built-in pylsp plugins) file above. I may update it to include the non built-in plugins as well. But yes, you would be better served to configure everything in your pyproject.toml if you can. I believe that is even the recommendation from the E-glot author.

@SeerLite
Copy link

SeerLite commented Mar 9, 2024

On the original issue: it would be helpful if this route of configuration (from the client) is in the readme, since the functionality seems to be there. I guess all you need to know is A: that it's indeed possible, and B: that you have to supply the options under plugins and then pylsp_mypy with the underscore. In hindsight I could have guessed it (being Python) and it's clear from the source, but hindsight is hindsight. :)

I agree with this. This issue should be renamed to "Document configuration from lsp" or something alike.

@Ae-Mc Ae-Mc changed the title Support configuration from lsp Document configuration from lsp Mar 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants