Can the supported IntelliJ version range be extended?
gSchurkus opened this issue · 19 comments
Is your feature request related to a problem? Please describe.
Thank you for addressing #329 in plugin version v0.0.32. Unfortunately, I cannot use that version currently, because we are still pinned to IntelliJ IDEA Ultimate 2023.1.3, and the plugin page lists any plugin version newer than v0.0.19 as incompatible with that.
Describe the solution you'd like
Is there a technical reason why the plugin is not backwards compatible to older versions of IntelliJ?
If the range could be extended with minimal effort then that would be great.
Since many companies upgrade their software on a bi-annual cycle, it would be ideal if the newest plugin version was always available with all prior year (and current year) versions of the IDE, i.e. currently Intellij IDEA v2023.* and Intellij IDEA v2024.*
Describe alternatives you've considered
I understand if extending the compatibility range is too much work. In that case, maybe you could comment on what the challenge is?
Thank you for creating the issue.
I checked briefly, for example, there seems to be no lsp related modules.
In other words, the current source code cannot be built for 2023.1.
To be honest, it is not very easy to prepare a version without lsp functionality.
https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-developers/
Thank you very much for the info. That makes a lot of sense to me. If the whole plugin is built on a protocol (lsp) that hadn't even been introduced yet in the earlier versions of the IDE, then creating that additional support really is not a viable option. Bummer, but thank you for looking into it :D
@fbricon
Thank you for sharing the project :)
@MichaReiser @snowsignal
Not directly related to the main topic of this issue, but what about using LSP4IJ?
Because @charliermarsh mentioned in talkpython that you are working hard on the LSP implementation.
If we stop manipulating ruff on the PyCharm plugin side and let ruff-lsp take care of much of the processing, whether pro or free version, we could benefit from the development of ruff-lsp.
If it matches your company's policy, I would like to consider this support as an optional feature.
I would appreciate your input.
@koxudaxi Thank you for asking! We do want the LSP to be the main method for editor extensions to interface with Ruff going forward. As you said, it's a lot less work on the extension side.
We have been working on a new Rust-based LSP server, ruff server, which comes built-in with ruff. So that should make things even easier to implement. 😄
I'm definitely interested in LSP4IJ! We've been concerned that Jetbrains LSP support is only available for paid versions, because we'd like the extension to be used by everyone. So if this gives us a way to support both free and paid versions, (with additional features, no less) that would be great!
You can start testing your LSP server today, with a nightly build of LSP4IJ, and manually add a language server definition.
Please note LSP4IJ only supports stdio connections for now.
@fbricon
I tried it as soon as possible. The warning came out well from ruff-lsp.
Can we fix the code by using only the user-definition method?
If the user-definition method is the easiest way to solve everything from settings to options, I'll be happy to finish developing this plugin 😅
However, if my plugin is useful as an integration for users to easily introduce ruff-lsp, I will continue to incorporate and develop the lsp functionality with LSP4IJ.
We have been working on a new Rust-based LSP server, ruff server, which comes built-in with ruff. So that should make things even easier to implement. 😄
This is exciting information. I was sure you guys would implement this in ruff someday. 🚀
I told @charliermarsh this in DM, but if there is anything I can do to help, please let me know.
I don't want to hinder your business by my slow development speed. I'm sure if I could commit to OSS full-time, it would solve the problem, but I can't find a good way to do it at the moment.
I can continue to develop it, or I can transfer the repo to your company, or I can archive my repo if you want to make it official from scratch in your company, no problem 😄
My goal is not to earn stars, but to provide a useful tool for everyone.
I will be giving a talk at PyConUS next month, so if you are going too, we might be able to talk then.
I don't know anything about ruff-lsp. I'll let you guys validate whether user-defined LS is good enough for you. If it is, then you can maybe open a PR to create a ruff-lsp template in https://github.com/redhat-developer/lsp4ij/blob/main/src/main/resources/templates/template-ls.json, with additional instructions, default settings and initialization options similar to https://github.com/redhat-developer/lsp4ij/tree/main/src/main/resources/templates/rust-analyzer.
Do not hesitate to open tickets in https://github.com/redhat-developer/lsp4ij/issues or ask in https://github.com/redhat-developer/lsp4ij/discussions to discuss about LS integration
Can we fix the code by using only the user-definition method?
I'm not sure what you mean here. If the LSP provides code actions for some diagnostics, then they should show up. If the fix is 100% managed on the server side, it should just work (or else it's a bug we'd need to fix). If the fix requires specific client integration, then that's out-of-scope of LSP4IJ, you'd need to provide a specific plugin integrating with LSP4IJ for that.
Now if you're not talking about code actions, then you'll have to provide more details ;-)
Now if you're not talking about code actions, then you'll have to provide more details ;-)
Sorry for the lack of explanation, I am not familiar with this, but I believe many users would like to invoke this request(textDocument.formatting) to fix the code from a keyboard shortcut.
In any case, I think I should play with lsp4ij first and then pose a detailed question to you.
Thank you!!
yeah formatting is not yet supported in LSP4IJ. You'll have to be patient ;-) My bad, on-type formatting is still missing, regular formatting queries should be supported. See https://github.com/redhat-developer/lsp4ij/blob/main/docs/LSPSupport.md for the detailed list of supported LSP features
Thank you so much @koxudaxi. I'm really grateful for all the work you've put into the extension. I'm sorry that I missed your DM on Mastodon -- I'm just seeing it now. Our main focus today is on making ruff server a full replacement for the ruff-lsp Python package (that's @snowsignal's project), then from there I suspect we'll start thinking about how to package it for other editors (e.g., we're focused on our own VS Code extension, but a lot of users have asked about an "official" PyCharm extension, we might also want something for Zed). I'll need to chat with @snowsignal and others to see what makes most sense, whether we'd want to start from scratch for IntelliJ or build on your work as a foundation (it's a very kind offer). Regardless I am sure we would learn a lot from the current version of the extension, including if it supported LSP4J. And, ideally, swapping out ruff-lsp for ruff server should be extremely straightforward.
My goal is not to earn stars, but to provide a useful tool for everyone.
You're a hero.
I will be giving a talk at PyConUS next month, so if you are going too, we might be able to talk then.
I'll be there! I would love to meet in-person.
@charliermarsh
Thank you for sharing specific policies despite your busy schedule.
I had hoped to deliver the ruff experience to as many people as possible through this project (the same goes for my Pydantic and Poetry plugin projects). If the existence of this plugin has reduced the number of users criticizing your project for not being usable in PyCharm, I am happy.
I just understood you still plan to allocate your team resources to the ruff server.
While you focus on the ruff server, I can implement integration with LSP4IJ in this plugin and gather user feedback.
Initially, this project implemented many features using only the ruff command, later supported LSP, WSL, followed the latest version of IDEA, and had to support multiple ruff versions (including changes in options). Therefore, the code of this project is not very clean and needs refactoring. Once the transition to LSP4IJ and the rough server is complete, the code of this plugin can be significantly refactored. This is good news for us.
If you were to build from scratch, since user requirements are already clear, I believe you could start with a much cleaner implementation.
ideally, swapping out ruff-lsp for ruff server should be extremely straightforward.
It's very cool 😄
@fbricon
It's good news.
I don't know if it will be ready for release this weekday, but we will work on it.
I expect to be able to release it next week at the latest.
@fbricon
It's good news.
I don't know if it will be ready for release this weekday, but we will work on it.
I expect to be able to release it next week at the latest.
@koxudaxi we have released last week LSP4IJ 0.3.0 which provides experimental LSP semantic tokens support.
Is there another thing that you need to adopt LSP4IJ ?
@fbricon @angelozerr @charliermarsh @gSchurkus
Sorry for the delay.
I have released version 0.0.36 of our PyCharm plugin, which now supports LSP4IJ.
Thank you very much!!
@koxudaxi first congrats. It is a fantastic news for LSP4IJ, thanks!
Please create a PR to add your plugin in https://github.com/redhat-developer/lsp4ij?tab=readme-ov-file#who-is-using-lsp4ij
@koxudaxi Congrats on the release! I can update the Ruff documentation to reflect this change :)