pylance-release
LunarVim
pylance-release | LunarVim | |
---|---|---|
50 | 272 | |
1,655 | 17,518 | |
0.4% | 0.9% | |
9.0 | 6.9 | |
9 days ago | 1 day ago | |
Python | Lua | |
Creative Commons Attribution 4.0 | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pylance-release
-
Open source versus Microsoft: The new rebellion begins
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!)
- Help! Connection to server got closed error
-
Pylance is not working on my vscode
Anyone know how can we fix this issue if we build the vscode locally
-
VSCode adding exactly one space to all my new lines??
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
- Pylance: String literal is unterminated
- What do you expect when renaming an import?
-
Writing Python like it's Rust
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-...
-
Any must-have extensions for working with Python in VSCode/VSCodium?
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 )
-
MSFT is forcing Outlook and Teams to open links in Edge and IT admins are angry
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
- Import ... could not be resolved
LunarVim
-
Every Neovim, Every Config, All At Once
LunarVim
- LunarVIM: An IDE Layer for Neovim
-
Tools to achieve a 10x developer workflow on Windows
I would suggest to start getting into vim by first trying out popular vim keybinding plugins available on your favorite code editor and get used to those first. Then, if you want to dive deeper into the power of Neovim, try out popular configs like LazyVim, LunarVim, NvChad... Taking Neovim from a mere text editor to a full-featured IDE with features like intellisense, debugging, testing, etc... on your own takes quite a lot of work and configuration.
-
Helix 23.10 Highlights
I used Helix for a while due to its support for LSP out-of-the-box, which my Vim config at the time couldn't live up to. I switched back to NeoVim after finding LunarVim[1] which had everything I was trying to get setup in my own config.
[1] https://www.lunarvim.org/
- How to Transform Vim to a Complete IDE?
-
Mastering Emacs
I'll admit I didn't look into it, but Helix sounds like something like LunarVim (https://www.lunarvim.org/)
Personally I much prefer that the editor NOT ship with something like that by default, especially when it's so easy to set up. I have several different vim config I use, including a pretty bare-bones one for headless systems, and I much prefer the ability to customize something very specifically.
Build tools that can compose together, rather than a single do-it-all tool. That is the power of the low level editors vs IDE's.
- No inline errors in Python unless I add and delete a line
-
LazyVim
I can't comment on any implementation details, but at least with LunarVim (which I use for daily coding), a slowdown when interacting with LSP is very noticeable. Some others have attested to this on a GitHub issue.
I'm not doubting your experiences with the lack of a slowdown, but there is truth that others do experience it. That might be more of a problem with LunarVim itself rather than Vim, but how likely am I (as someone who would like to avoid what he calls "config hell") or other newcomers to avoid whatever pitfalls there are, if a distribution designed for ease of use by people who know better fall into them?
https://github.com/LunarVim/LunarVim/discussions/3359
- Should Neovim now release a standard official configuration so that people who want an editor that just works out of the box get onboarded easily ?
-
neovim config
Anyways, although i have not used them, LazyVim and LunarVim comes highly recommended. You can try these and see what suits you .
What are some alternatives?
pyright - Static Type Checker for Python
AstroNvim - AstroNvim is an aesthetic and feature-rich neovim config that is extensible and easy to use with a great set of plugins
jedi-language-server - A Python language server exclusively for Jedi. If Jedi supports it well, this language server should too.
SpaceVim - A community-driven modular vim/neovim distribution - The ultimate vimrc
vscodium - binary releases of VS Code without MS branding/telemetry/licensing
NvChad - An attempt to make neovim cli as functional as an IDE while being very beautiful , blazing fast. [Moved to: https://github.com/NvChad/NvChad]
emacs-jedi - Python auto-completion for Emacs
NvChad - Blazing fast Neovim config providing solid defaults and a beautiful UI, enhancing your neovim experience.
neovim - Vim-fork focused on extensibility and usability
Neovim-from-scratch - 📚 A Neovim config designed from scratch to be understandable
nvim-lspconfig - Quickstart configs for Nvim LSP
LazyVim - Neovim config for the lazy