question: possible contributions - binary installation location

[zettlrobert]

TLDR - Contribution Guidelines? Open for PRs?

Current Preference

I have a setup that installs some default lsps, formatters and other required binaries into the nvim specific $HOME/.local/share/nvim directory, independently from similar binaries on my system.
An additional lsp should follow that convenience

Feature Idea

Would you be open to prs that provide a config flag for example auto_install_prerequisites/auto_install_binary or similar to have a 'bundled' experience.
How and if the global and scoped versions could share the cache ($HOME/.cache/trunk) is something that I would have to look into.

Or even a Mason integration?

Reasoning

I personally like for my 'editor' to be able to install all servers and required binaries without messing with 'global' packages and path (keep the non project related path as small as possible).

Variables local binaries as well as systems constraints could change over time and projects - (disregarding containerized development and nix-shell or similar for the sake of the argument).

Generic Setup Question

Additional Question before I try out the plugin.
Do you suggest disabling for example null-ls or none-ls as they seem to provide the same or at least similar functionality with there own implementation

Best Regards

[TylerJang27]

Hi @zettlrobert! Thanks for reaching out!

Short answer: Yes, that all sounds great!

Long answer:

Bundled install

I definitely get the motivation here, and our VSCode extension (which this is designed to replace/mimic) auto installs the binary for you. In this case, we would probably want 2 fields, such as:

• auto_install_binary (default true)
• install_binary_dest (default ~/.cache/trunk/launcher)

Mason

I haven't used Mason before, but that's definitely a good suggestion. I'll have to look more into their specifics, but we provide our launcher as an npm package here.

Null-ls

Although I haven't used it before, I suspect neovim-trunk would be a replacement for most of null-ls's features (although we do not support completion or range formatting). It may be that the optimal usage involves fine tuning both.

Contributions

While the trunk binary itself is closed-source, we welcome open source contributions here and to our plugins repo (where our linters are defined)! If you want to undertake any of these, we would definitely welcome the effort. I'm happy to help brainstorm any specifics/ideas, but all that you've described sounds great!

[zettlrobert]

Hi @TylerJang27 i appreciate your answer!

My first step will be to sort out a local installation get everything setup and take a look on how and if all the tooling works together.

If I find the time and decide to implement the above integrations. I will come back with a draft/proposal to brainstorm on.

Thanks again for the Long Answer your time and effort are really appriciated!

[TylerJang27]

Sounds good! Let me know if you need any help getting it set up. Note that the current implementation (as you saw) requires trunk to be in your PATH.

Auto installing the binary definitely aligns with our goals for this plugin, so we'd love to have it!