Remove plenary.nvim as a hard dependency.

[231tr0n]

Hi! Are there any plans to remove plenary.nvim as a hard dependency for this plugin.

[ckipp01]

Good question. Honestly, I'd like to, but we're pretty integrated with it in here. I use it for the following things:

• plenary.job which ends up being much easier to use then if we had to code it ourselves. I did it without plenary very early one, and it wasn't super nice. We use this mainly for the install process of metals
• plenary.path we use this all over the place for finding the metals path, and all other path related things. If we only used this, then we could probably copy some helpers to deal with paths more easily and call it a day, but it's the usage of other stuff which makes this fine
• plenary.curl we use to get the latest Metals version quickly to be able to know what the latest snapshot is for those that use latest.snapshot as their version
• plenary.window.float we use for things like :MetalsInfo. We could easily replace this one as well, but again, since we use other stuff it wasn't a big deal

So I guess the question becomes is replacing all of this with hand-coded alternatives worth it. Are you having any issues with plenary being a hard dependency?

[231tr0n]

Thank you for the reply. The reasons for which I suggested this are as follows :-

1. This is the main issue I have and to be honest, I dont have any plugins which use plenary.nvim as a dependency.
2. It seems to be barely maintained with no releases what so ever and a lot of issues.
3. It ships a lot of functionality which I as a end user dont use at all but have to load it.
4. As a language related plugin, it is generally not expected that nvim-metals has any neovim lua dependency except for the lsp, debug and test related tooling installed properly. nvim-jdtls which is similar in terms of serving usecase like nvim-metals does this and is not dependent on any other plugins and is a standalone one. I dont want to compare nvim-metals to nvim-jdtls and say nvim-jdtls is doing it right, but I feel it would be really good if nvim-metals goes this way.

[ckipp01]

Hey @231tr0n, so I guess a couple things come to mind.

It ships a lot of functionality which I as a end user dont use at all but have to load it.

You actually don't need to load it all. With Lua if you're requiring a specific module, like plenary.path or something you're only loading that module, not all the other modules in Lua. So you don't really need to worry too much about this and it shouldn't cause any issues.

As a language related plugin, it is generally not expected that nvim-metals has any neovim lua dependency except for the lsp, debug and test related tooling installed properly.

I mean, not expected by whom? This has been the first report of this every being an issue.

nvim-jdtls which is similar in terms of serving usecase like nvim-metals does this and is not dependent on any other plugins and is a standalone one. I dont want to compare nvim-metals to nvim-jdtls and say nvim-jdtls is doing it right, but I feel it would be really good if nvim-metals goes this way.

So nvim-jdtl is fantastic, as it all of his plugins, and I drew a lot of inspiration from it when I first started. However, nvim-metals is quite different in that we do a lot of the setup for the user where nvim-jdtls requires quite a bit more manual setup to get up and running. That main difference is where a lot of this is used.

With all that being said, I'll do a bit of exploring to see how feasible it would be to get this removed.

[231tr0n]

Hey @231tr0n, so I guess a couple things come to mind.

It ships a lot of functionality which I as a end user dont use at all but have to load it.

You actually don't need to load it all. With Lua if you're requiring a specific module, like plenary.path or something you're only loading that module, not all the other modules in Lua. So you don't really need to worry too much about this and it shouldn't cause any issues.

You are right about this part. But honestly speaking, I am minimalistic guy and only install plugins which are required or are directly used by me unless necessary. This is mostly preference related. You are free to take this point with the importance of a grain of salt if required.

As a language related plugin, it is generally not expected that nvim-metals has any neovim lua dependency except for the lsp, debug and test related tooling installed properly.

I mean, not expected by whom? This has been the first report of this every being an issue.

Well, what I meant by this was since it is a language related plugin and not any neovim functionality related, the only thing which it should depend on are the installation of coursier or scala related development tools. nvim-dap is an excecption since there is no way to debug in neovim other than using that, but other than that it would really help if this plugin works in standalone without any kind of dependencies. That was my expectation behind this point.

nvim-jdtls which is similar in terms of serving usecase like nvim-metals does this and is not dependent on any other plugins and is a standalone one. I dont want to compare nvim-metals to nvim-jdtls and say nvim-jdtls is doing it right, but I feel it would be really good if nvim-metals goes this way.

So nvim-jdtl is fantastic, as it all of his plugins, and I drew a lot of inspiration from it when I first started. However, nvim-metals is quite different in that we do a lot of the setup for the user where nvim-jdtls requires quite a bit more manual setup to get up and running. That main difference is where a lot of this is used.

With all that being said, I'll do a bit of exploring to see how feasible it would be to get this removed.

Thank you for considering my proposal :).