@justinmk, thanks for all your work and leadership on neovim. I'm not excited about this feature, but in general I am excited about the changes I've seen in the project. Making a text editor is definitely not my life's ambition, but I'm glad you're taking up the challenge.

...

I don't really agree that "New users must look for a plugin manager and figure out how to install it". The only users who need to do that are the ones who have already found a plugin that they want to install, and which also doesn't provide installation instructions of its own. I don't agree that "Lack of a declarative way to specify plugins" is a valid problem, since this problem is actually introduced by bundling a plugin manager.

And this justification for creating the feature completely ignores the several high-quality existing, unbundled implementations of plugin managers. The installation of Lazy.nvim is entirely within your nvim init files, demonstrating that 3rd-party plugin managers can have simple installation instructions.

The bundled package manager also makes some trade-offs that 3rd-party ones don't have to make (e.g. support for non-git plugins). This is addressable, like the lack of lockfiles, automatic dependency management, and re-implementing every other feature that existing plugins already provide. That's why this is bloat. This task is better-served outside of the core project.

	▲	justinmk 4 days ago \| parent [-]
		When problems get solved, the remaining problems become more salient. The most salient feedback we get in the last 3+ years is that the "getting started" UX has too much friction. (And this affects old users too, whenever I install Nvim on a new machine without my bag-of-tricks, I notice where friction is.) For most users that want LSP, or even just to try Nvim for 2 minutes to see what it can do, it's not acceptable that our intro docs have to say "go here or there to install this or that plugin manager, and read their docs, then come back...". Being able to say "add vim.pack.add(http://...) to your config, then :restart", is a complete answer. vim.pack is relatively tiny (low maintenance), and zero performance cost for users that don't use it. Not bloat. It's the opposite of bloat, because it allows us to more often choose "runtime-dependencies", instead of "shipping the universe" in the default build. That's a very welcome "release valve". - Example of "shipping the universe": Vim's 1000+ builtin syntax files, ftplugins, etc. - Example of "runtime-dependencies": nvim-lspconfig, treesitter parsers. > The only users who need to do that are the ones who have already found a plugin that they want to install, You skipped some steps. > automatic dependency management None of the existing plugin managers do that, except luarocks.