pylsp-rope VS pylance-release

pylsp-rope is actually an external plugin project, it implements advanced refactoring functionalities using code action (extract method/variable, function inlining, converting local variables to instance variables, organise import, etc). Unless you have explicitly installed pylsp-rope at some point, it's unlikely you already have it in your system. I'm the author of pylsp-rope, btw.

If you're also a user of rope, which is a Python refactoring library, my python-lsp-server plugin pylsp-rope would also welcome contributions. They have a fairly small codebase, and so they would be relatively easy to pick up.

Currently the best way to use rope for refactoring (including extract, inlining, reorganise import, plus many more) in Neovim is with pylsp-rope and your preferred LSP client. pylsp-rope is going to be the main focus of bringing rope capabilities to various IDEs and text editors. I'll have to find the time for this, but I'm planning to overhaul the rope support in core pylsp to make it work even better.

Rope's Restructuring refactoring is very powerful and flexible, and it's very accurate given the pattern, however it's currently only accessible from rope's programmatic interface, which means you have to write a little bit of Python code to use it. I've not been able to figure out how best to expose this capability into easy to use user interface within text editors/IDEs and especially within the constraints of LSP for pylsp-rope.

I am the maintainer rope and pylsp-rope. They are libraries for automated Python refactoring and to do that from any LSP-capable editors. We are always welcoming contributors of all levels.

You can also use pylsp-rope, though until LSP actually provides a standard Villani compliant interface that allows LS to implement move refactoring, you may not be able to use it from your editor. I'm kinda thinking that maybe I should just non-standard LSP extension that ropevim would call into. It shouldn't just be Microsoft that can play EEE 😅

pylsp-rope

I never had to market an open source project from zero that later grow into popularity, but I did inherit the maintainership of a fairly popular project and then I started a new project that have been gaining a small, but growing momentum.

Most of my personal projects are written because I need a feature that nobody else has anything remotely resembling what I need.

pylsp-rope for refactoring capabilities

One of the things that comes to mind here is the fact that the default Python extension for VS Code is, perhaps surprisingly to many, not open source. https://github.com/microsoft/pylance-release

While it's possible to fork VS Code, it is not possible to fork VS Code and provide a seamless onramp towards a Python editing experience that is fully open source, because users are used to the nuances of the closed-source Pylance experience in VS Code proper. You could use the minified/compiled Pylance plugin in your fork, but you'd have no way to expand its capabilities to new hooks your fork provides. Microsoft's development process would always be able to move faster than a fork, because it could coordinate VS Code internal API development with its internal Pylance team, and could become incompatible with forks at any time.

It's worth re-reading the quote from J Allard in https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... with this modern example in mind.

(Also worth mentioning https://github.com/detachhead/basedpyright?tab=readme-ov-fil... which is a heroic effort to derisk this, but it's an uphill battle for sure!)

Anyone know how can we fix this issue if we build the vscode locally

Do any of these issue tickets explain the behaviour you're seeing? https://github.com/microsoft/pylance-release/issues/4341, https://github.com/microsoft/pylance-release/issues/4071

Maybe they "are the same thing" in terms of behavior (I don't know), but "A uses B" doesn't mean that "A is B".

One important difference in this case is that while "Pylance leverages Microsoft's open-source static type checking tool, Pyright" [1], Pylance itself is not open source. In fact, the license [2] restricts you to "use [...] the software only with [...] Microsoft products and services", which means that you are not allowed to use it with a non-Microsoft open source fork of VS Code, for example.

The license terms also say that by accepting the license, you agree that "The software may collect information about you and your use of the software, and send that to Microsoft" and that "You may opt-out of many of these scenarios, but not all".

[1] https://github.com/microsoft/pylance-release

[2] https://marketplace.visualstudio.com/items/ms-python.vscode-...

There's this one: https://github.com/microsoft/pylance-release/issues/4174 (rules don't apply properly, and ovverrides don't work even after being set, this is especially for the more generic ones like )

The example is not .NET in general, but that specific event when Microsoft reneged on open development tooling[1]. For some people, that was the moment they stopped trusting "new Microsoft" to keep their word (though for me, it was when the Python language server was replaced with a DRM-locked, LSP-noncompliant one[2] a bit before that; unlike .NET hot reload, they didn't backtrack there). I can think the company makes great open .NET tools and at the same time not trust them to close it down on a whim.

Does anyone know where the open xlang reimplementation of MIDL went[3], by the way? (Unlike 1990s MIDL, you can't reimplement this one from the language grammar in the docs, because there is no language grammar in the docs.)

[1] https://dusted.codes/can-we-trust-microsoft-with-open-source and links there

[2] https://github.com/microsoft/pylance-release/issues

[3] https://github.com/microsoft/xlang/pull/529