Dependency triaging RLS and async/await
workingjubilee opened this issue · 3 comments
While rust-analyzer is the preferred LSP solution, rust-analyzer still cannot fully replace RLS and RLS is still a tested submodule of rustc, and will likely be used for some time by the community. Accordingly, RLS could use a little tender love and care to its dependency tree, as rust-analyzer has gotten most of the action here.
A main source of "dependency decay"... dependence on old code that isn't getting much security/compat/enhancement maintenance... is the usage of mostly pre-async/await
code in RLS and its dependencies. This currently keeps RLS stuck on an older version of futures and tokio. There are three major, obvious options:
- Wait for paritytech/jsonrpc#485 to resolve
Pros: Lazy!
Cons: Parity began work onjsonrpsee
to replace it, so it may never be moved fully over to tokio 0.2 - Move jsonrpc -> https://github.com/paritytech/jsonrpsee as it becomes available
Pros: Newer, maintained dep, eventually no loss of features?
Cons: New, untested, possibly feature-incomplete for RLS' use-case. - Write some blocking JSON IPC as suggested here rust-lang/rust#75704 (comment)
Pros: Less dependence on complicated/newer features. Simplifies dependency tree greatly.
Cons: Forfeiting async benefits, more effort, taking on maintenance burden directly
I'll look into this this week; @workingjubilee thank you for the detailed write-up!
Update: paritytech/jsonrpc#485 is now fixed via paritytech/jsonrpc#603, so I believe this should be the way forward here, once jsonrpc is released including that PR.