About the Upcoming 0.7.0 Release (mostly related to codecompanion integration)

[Davidyz]

The upgrade from 0.6.x to 0.7.0 is going to contain some breaking changes. The relevant PRs are labelled as breaking (there will be more coming). For the CLI, it's mostly just some deprecated features that will actually be removed. The neovim plugin side (especially the codecompanion extension) is a bit more complicated. I'll briefly introduce my plan for the upcoming release, and if you've any questions and thoughts, we can sort them out and make 0.7.0 a better experience for the community.

The current (<0.7.0) codecompanion tool implements the query and ls subcommands of the CLI. In other words, it gives the LLM read-only access to the database: the LLM will be able to see the indexed projects and query from certain projects. In 0.7.0, I plan to give it write access: it'll be able to vectorise files. With the existing implementation, this will add an extra layer of complexity to the tool schema, making it more challenging for the LLM to follow.

Thus, I think it's better to just split the existing vectorcode tool into several tools (most likely to be named @vectorcode_query, @vectorcode_vectorise and @vectorcode_ls), each responsible for one specific subcommand. This will allow you to control what you want the LLM to have access to. If you want to maintain read-only access, that's fine. You'll be able to just choose not to give the LLM the vectorcode_vectorise tool. If you want to take this one step further and just prevent the LLM from exploring outside of your current project, you'd be able to choose not to give it the vectorcode_ls tool. For your convenience (and mine, too), the codecompanion extension will provide a tool group that contains all vectorcode tools, as well as some system instructions on how the tools may be used together.

The above changes will, however, make the structure of the native function calling tool (the default) vastly different from the legacy XML-based tool. Maintaining both of them is a lot of burden, especially if you take the changes in codecompanion into account. Therefore, I plan to stop maintaining the legacy XML-based tool. If you're still using it, please consider pinning VectorCode (both the CLI and the neovim plugin) to 0.6.13.

Also, since nvim-lspconfig has frozen the lspconfig.<server>.setup syntax and moved to the new lsp/<server>.lua syntax for LSP configuration, I'll stop loading LSP configuration from nvim-lspconfig manually and only load it from vim.lsp.config.vectorcode_server. It'll make the code cleaner and easier to maintain. This'll mean that you'd need nvim 0.11+ to use the LSP backend (or, you can manually start the LSP server before the plugin loads. It'll probably work, but I won't be supporting this).

I hope that this is a release that will make our lives easier when working with code repositories, and one that makes us feel safer when sending data, public or private, to the LLM (and whatever cloud service providers that host them).

Happy Vector-Coding!

[petobens]

Hi @Davidyz! Given this is a breaking change release, are there any plans to also include #36?

[Davidyz]

Hi @petobens , the migration to chromadb 1.0.x is significantly more breaking than what's being included in this PR because you'd need to go to every single project that you've vectorised and re-vectorise them. The currently planned 0.7.0 release, on the other hand, should work OOTB if you haven't manually written any configs and used the default values for everything.

Also, @rieger-jared has gracefully volunteered to try to refactor the database stuff with more abstraction so that we can attach different databases to VectorCode (#165 ). If this works, we'd be able to get Chromadb upgrade for free (because we can just make a different connector for Chromadb 1.0.x). However, this will probably be a very time-consuming process, because the Chromadb API calls are scattered everywhere.

That said, I am as keen as you (if not more) to bump the chromadb version to 1.0.x, and if I had to do it as a breaking change, I'd do it when we bump VectorCode from 0.x to 1.0 (so that it actually looks like a more significant change).

I hope this makes sense.

[petobens]

Perfect sense. Thanks for the explanation.