Usage with Neovim

[johnallen3d]

First let me say that I'm finding the design of tea very intiutive and magical to work with! I've been a longtime proponent of using Docker for dev environments but have recently found myself souring on that approach (could be because M1 Macbook Pro is sooo fast). While reading the tea cli README the rant on Docker for dev really hit home.

As a test case I installed tea and started using it for the Advent of Code excercises (learning some Go) and it worked beautifully!

I wanted to take it a step further over the holiday break so I've been attempting to replace packages installed with Homebrew with their counterparts from the Pantry. Thus far this is working out quite well using the function fish_command_not_found hack. 🎉

Next I fired up my preferred editor, Neovim, and realized a couple of plugins I use were not working. After doing some digging (:checkhealth) I realized that these plugins were relying on external dependencies (e.g. jq, rg) being installed and present on $PATH. I did some searching (issues, discussions) to see if anyone else has reached this point but didn't. I stumbled across this suggestion create a shell script to wrap tea and that approach is working for me thus far. However, as it turns out, the Neovim plugins I'm using are relying on quite a few external dependencies.

~/bin/tea
❯ ls
fd
go
jq
node
npm
rg
wget

Not that big a deal, it only took me a couple of minutes set these up, but I'm wondering if there's something I'm missing. Is there an approach I should be taking to make my editor aware of tea packages? Is this planned for the future?

Thanks for this fantastic project and happy holidays!

[jhheider]

There was a PR, but possibly no documentation, that allowed the following to work: sudo ln -s tea /usr/local/bin/jq, etc. This should satisfy anything that requires finding binaries on your path, as long as it's ok with symlinks. Basically, any symlinks to the tea binary functions the same as tea -X foo, where foo is the basename of the symlink.

[johnallen3d]

Thanks for the response @jhheider. Now that you mention it, I recall reading the following in the README:

Notably if you create a symlink of foo to tea (or tea_foo) we will interpret that as tea -X foo [args…], yet another way using tea can be completely transparent to your everyday workflows.

This seems to work well for my use-case and (IMO) is a better solution than mine (shell script wrapper). 👍

[mxcl]

Hi John! So glad you are enjoying tea as that is what I truly hoped when we started this project: for it to become a delightful tool for all developers of all stacks everywhere.

We are planning to write a VSCode extension that magically makes any deps you need available as virtual environments for each project when you open them, this work will help us understand how we can do the same for all such editors, including NeoVIM.

Our approach is new so editors etc. will need us and the community to come up with ideas for how integrations will work. Some of these ideas may have to be innovations! And those innovations will lead to more stable ideas that the editors can adopt. Or those ideas may just work so that nothing more is needed.

Certainly the tea-symlink system is working for now (I use this so extensions find their tools with VSCode as an interim solution until we make the viscose extension). Though longer term I feel you should only need to “install” tools that represent some level of permanence in your day to day workflows.

Anyway, would love to hear your thoughts and we're here to help you with tea! Thanks again.

[johnallen3d]

As for the direct Neovim dependencies (e.g. Python or Ruby), I might be the worst person to ask as I typically disable those integrations. 🤷

I do have some thoughts about where tea could be of great advantage to plugin dependency management.

First allow me to set the table with the differences, as I see it, between the VS Code extension and Neovim plugin landscapes. Because Neovim doesn't have a centralized marketplace the ecosystem is quite different from VS Code. In Neovim you either see plugin announcements (e.g. r/neovim) or you are searching GitHub hoping you get the keywords correct (similar to Go I suppose). Another difference is that Neovim plugins that require an external dependency do not (typically) manage installing that dependency for you. For example if a plugin provides fuzzy search, it might rely on ripgrep, but it's up to the user to get that installed and on the $PATH.

There are plugins that do install the dependencies for you as well as plugins that are dedicated to dependency management. The most prominent (IMO) of the latter is mason.nvim. Mason is essentially a package manager focused on LSPs/linters/formatters that can then be integrated with the in-built Neovim LSP client (via another plugin like nvim-lspconfig. This strikes me as a potential use-case for tea. Essentially replace the package download/build/install features in mason.nvim with tea and allow for the plugin to focus on the UX for managing packages. Of course this assumes @williamboman would have interest in this integration.

Anyway, I'm very interested in this topic and your response sparked some ideas. I realize what I'm suggesting here isn't the same as the VS Code extension you mention (providing project specific virtual environments) but I can see many avenues for the application of tea in this arena!

[jhheider]

Build had failed; kept showing a dns resolution isuse. Seems to be resolved now. https://github.com/teaxyz/pantry.extra/actions/runs/3787885191

[johnallen3d]

Thanks for the followup @jhheider, it's working now. 🙂

❯ tea +neovim.io nvim --version
tea: installed: ~/.tea/gnome.org/libxml2/v2.10.3
tea: installed: ~/.tea/gnu.org/gettext/v0.21.1
tea: installed: ~/.tea/neovim.io/v0.8.1
NVIM v0.8.1
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /opt/tea.xyz/gx/cc/v0.1.1/bin/cc -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -DNVIM_TS_HAS_SET_ALLOCATOR -O2 -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/opt/neovim.io/src/v0.8.1/build/cmake.config -I/opt/neovim.io/src/v0.8.1/src -I/opt/neovim.io/src/v0.8.1/.deps/usr/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX12.3.sdk/usr/include -I/opt/gnu.org/gettext/v0.21.1/include -I/opt/neovim.io/src/v0.8.1/build/src/nvim/auto -I/opt/neovim.io/src/v0.8.1/build/include
Compiled by [email protected]

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/opt/neovim.io/v0.8.1/share/nvim"

Run :checkhealth for more info

I've brew uninstall neovim and symlinked to tea, so far so good!

[mxcl]

Def need to improve this error

[mxcl]

Mason.nvim is very interesting in that, yes, I think tea would do a really nice job here. Things like mason.nvim can use tea to easily get packages (just do tea -X foo) or someone could write a tea.nvim if they wanted.