Migration from DAPInstall.nvim about dap-buddy.nvim HOT 12 OPEN

Hey all! Thought I'd chime in here with some of my plans. While https://github.com/williamboman/nvim-lsp-installer so far only targets LSP servers, there's nothing special about the management of LSP servers that would motivate solely targeting LSP servers. So, I've been working towards repurposing the existing installation and TUI infrastructure for other purposes (linters, formatters, DAP, even plugin management, etc.). So far the effort has been put into decoupling internals and rework some things to provide nicer APIs, as well as thinking a bit more about how to best deal with PATH to improve interop with other plugins (the lsp_installer.on_server_ready() thing really needs to go). [ideally the installer plugin(s) would require no custom code in user configs, it'd manage PATH seamlessly]

What I've been thinking is extracting the core modules to an installer-core.nvim plugin. This would host the APIs necessary to write installer functions, and all UI components. This core plugin would then be used by separate installer-lsp.nvim, installer-dap.nvim, installer-linters.nvim, etc. plugins (preferably under a single org for better governance, accountability, and ownership). Alternatively, providing a single installer.nvim plugin that would host all types of installers. I find the first approach more appealing from a maintenance point of view.

There are two items remaining before I'll start looking into my ideas above:

1. further decouple some internals in nvim-lsp-installer (the UI stuff primarily)
2. change how PATH is managed so that all executables will be symlinked to a single directory, allowing us to simply modify the PATH once, and that'd bring in all installed servers (interacting directly with lspconfig, rust-tools.nvim, etc. would work seamlessly then)

from dap-buddy.nvim.

Heya!

you could've done that more carefully

True. Not trying to justify what I did, I really should've explained publicly my reasons for doing this (did it in Reddit comment, but should've announced something here). My bad! :)

for example, rewrite might deserve a new repository where the previous one could still exist for an archival purpose

Nope, my reasoning is that they are the same but one (dap-buddy) is going to be better than the other. The other one could perfectly live inside the commit history and since most plug-in managers can point to an specific one there shouldn't be a problem.

Is there any documentation/tracking issue/migration guide available? I cannot find any documentation/README at this point

Not yet, I will open it in a bit.

Probably you are still working on that, but any information would be appreciated.

I can share the features I've planned so far here actually:

• Centralized local database model
• Synchronous and asynchronous installation (better for automation purposes)
• Handy TUI with management features (e.g. installing, uninstalling, updating, getting info, ...)
• Better handling of dependencies
• Better CLI (i.e. installing multiple debuggers at the same time + error proof assertion)
• API for whatever outside interaction needed
• Support for *Unix and Windows
• New settings for debuggers: proxy, deps, applicable filetypes, ...

Plausibly possibly possible yet very likely to be included:

• An update command?
• Precompile configs to make them faster? (This seems unnecessary in my opinion but would be neat to have nonetheless

Right now there is only a blueprint with boilerplate code that works well, so it looks promising!

New ideas are, as always, welcomed!

from dap-buddy.nvim.

I just made https://github.com/williamboman/mason.nvim public for alpha testing. Feel free to give it a spin if you'd like, for the time being only a small set of new packages have been added on top the nvim-lsp-installer base (PRs to add new packages are very much welcomed). I'll let it settle for a while now before looking into releasing some stable release branch - any feedback until then would be much appreciated! (again, disclaimer: very few DAP servers have been added so far as my focus has not been there yet)

For those who currently use nvim-lsp-installer and want to switch entirely during testing (which I recommend), the minimum you need to get started is:

require("mason").setup()
require("mason-lspconfig").setup()

Note that you will have to manually clean up the old installation directory that nvim-lsp-installer used - mason installs to a new one by default.

from dap-buddy.nvim.

Cool! It's not quite ready just yet, hopefully it is in the next week or so. I will probably create a new repo altogether and let you know!

from dap-buddy.nvim.

@williamboman yes I had this idea a while ago! Well, not mine but I remember that under a post of mine or something someone commented about making a generic installer for nvim related tooling. Something every editor must have.

I replied with something along the lines of "I'll take on the challenge." But left it there and ended up just writing it down a couple of nights ago where a rewrite of DAPInstall resurfaced. (I'll try to look for the comment.)

In the mean time, I'll try to look deeper into how to get something like this to become a reality. Shouldn't be too hard as other projects already exist that try to achieve something like this. What I'm questioning is whether interfaces should be provided to interact with those tools (i.e. running a linter), or just, you know, manage them.

Anyways, I'll try to get back once I have got something working :)

from dap-buddy.nvim.

@williamboman create a branch for this beta release, post it on r/neovim. More people would know about this beta and should be happy to help us around.

I can pick up some during weekend and give you results.

from dap-buddy.nvim.

Until dap-buddy get documentation etc ready, we can I think use "dev" branch which still has older code. Once we learn about dap-buddy how to setup and install, we can move to dap-buddy main branch.

from dap-buddy.nvim.

@williamboman this sounds really awesome. I really like how the downloads are handled in your plugin having the same for dap sounds just amazing.

from dap-buddy.nvim.

Also, I believe null-ls achieves some of this.

from dap-buddy.nvim.

Hello again, so I've been hard at work refactoring things per my previous comment (so far 500 files changed, 7117 insertions(+), 6761 deletions(-) 😬). Would anyone be interested in "beta" testing and give early feedback for what I've come up with? Installation of DAP servers is from this point forward the easy part as everything is prepared for that. What I'm not sure about is what kind of API should exist to make it easier to actually use these installations with nvim-dap (and other DAP plugins). I've been thinking of potentially providing some adapter APIs that are tailored for a specific plugin in mind, roughly something in the lines of:

   local installer = require("installer-plugin-name-tbd").adapters.nvim_dap

    -- OPTION 1
    -- Provide functions that receive user config and decorates these accordingly
   dap.adapters.python = installer.adapters.python {}
   dap.configuration.python = installer.configuration.python {
       {
       -- user custom
       }
   }

   dap.adapters.go = installer.adapters.go {}
   dap.configuration.go = {
    installer.configuration.go {
        type = 'go';
        name = 'Debug';
        request = 'launch';
        showLog = false;
        program = "${file}";
    }
   }

   -- OPTION 2
   -- Expose configuration fields as standalone fields, users are required to access these manually.
   dap.adapters.python = {
      type = 'executable';
      command = installer.adapters.python.command;
      args = { '-m', 'debugpy.adapter' };
   }
   dap.configuration.python = {
       {
       -- user custom
       }
   }

   dap.adapters.go = {
       type = 'executable';
       command = 'node';
       args = installer.adapters.go.args;
   }
   dap.configuration.go = {
     {
        type = 'go';
        name = 'Debug';
        request = 'launch';
        showLog = false;
        program = "${file}";
        dlvToolPath = installer.adapters.go.dlvToolPath
    }
   }

Sneak peak:

from dap-buddy.nvim.

@williamboman i would more then be happy to test out the beta version!

from dap-buddy.nvim.

@williamboman awesome! I'll give it for a spin and give feedback in the repo. Thanks!

from dap-buddy.nvim.