Migration from DAPInstall.nvim

[wookayin]

I just found that you rebranded the plugin DAPInstall.nvim to dap-buddy.nvim.

However, this breaks everything about previous dap_install. An existing configuration will be broken and it looks like that you've changed a lot from DAPInstall.nvim. No :DIInstall commands any more, etc.. Well, I'm not sure such a sudden changing to a seemingly different project was a good idea; or you could've done that more carefully -- for example, rewrite might deserve a new repository where the previous one could still exist for an archival purpose. Or if it's still not fully complete yet, why not having them in a dev/unstable branch rather than main? But I can do see and understand the rational you've got for this rebranding.

Anyway congratulations on the major refactoring and rebranding. Hope the new one is better than the older one. But I'm now completely lost how to use the new one. Is there any documentation/tracking issue/migration guide available? I cannot find any documentation/README at this point. Probably you are still working on that, but any information would be appreciated.

For now, I'll need to pin the plugin version at 24923c3, but look forward to myself migrating to the new one soon.

[pocco81]

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!

[sultanahamer]

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.

[williamboman]

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)

[616b2f]

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

[pocco81]

@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 :)

[pocco81]

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

[williamboman]

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:

click to expand

   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:

[sultanahamer]

@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.

[Relms12345]

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

[williamboman]

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!