Stop breaking users' configuration.

[cyanpencil]

I appreciate all the time it has been invested in this plugin. I find it useful and I think it's currently the best NeoVim llm integration.

I'd like to ask contributors (especially, the main maintainer @olimorris) to pay very attention to avoid breaking the users' configuration when updating this plugin.

This is very important! Breaking people's setup is disruptive and annoying. It leads to two outcomes:

• Users will stop updating your plugin
• Users will switch to another plugin

The recent update on how adapters are configures (adapters.opts being deprecated and switched to adapters.http) broke my configuration. This is the second time that happens, and really makes me lose confidence in a project I otherwise really like!

Adding a notification at the start about the adapters change is also not an option. You can't simply print a message every time neovim starts to alert users of your breaking changes. This breaks even more users' workflow.

@olimorris, if you want this extension to be considered a serious productivity tool, and not just a toy proof of concept, your users' workflow is untouchable.
As Linus Torvalds repeated many times, "We don't break userspace". This is the success behind linux: a stable and trustworthy environment to get work done.

[olimorris]

@cyanpencil - This may come as a surprise to you, but I don't get paid for CodeCompanion. It firmly falls into the category of free and open source. It is simply my free gift to the Neovim community. You're welcome to use it. You're welcome to clone it. You're welcome to never pick it up again. It's your choice and the cost of doing so will be nothing. Because it is my free gift to you.

https://world.hey.com/dhh/open-source-is-neither-a-community-nor-a-democracy-606abdab

Addressing some of your comments:

Breaking people's setup is disruptive and annoying

I agree. And in your example, CodeCompanion didn't do this. A deprecation message is not breaking a persons setup.

Adding a notification at the start about the adapters change is also not an option. You can't simply print a message every time neovim starts to alert users of your breaking changes.

Firstly, it very much IS an option. CodeCompanion uses vim.deprecate - a native Neovim function - to alert users to this. It happens once every time you open Neovim. I choose to alert people so their config doesn't really break when I remove that feature.

A quick GitHub search for vim.deprecate will show you that this is a commonly used practice.

My advice - use a plugin manager to pin CodeCompanion to a specific version if you wish to use it. And set:

vim.deprecate = function() end

in your config to hide these warnings in the future.

if you want this extension to be considered a serious productivity tool, and not just a toy proof of concept, your users' workflow is untouchable.

I don't. I really don't mind either way. Whether Linus uses it or DHH uses it, the impact on myself is zero. If it's a toy for one user or a productivity game changer for another, the impact on myself is again, unfortunately zero.

[coolapso]

just stumbled on this ... how do I disable a particular message? I want to disable the new:

[WARN] CodeCompanion.nvim will experience breaking changes soon. Pin to version v17.33.0 or earlier to avoid this.
See: https://github.com/olimorris/codecompanion.nvim/pull/2439

have it pinned to the latest version and don't really want to disable the all the vim.deprecate messages, I find them really useful when they are actionable, but this one unfortunately there isn't much that can be done. I've pinned the version on the plugin manager but codecompanion is not (obviously) aware of that, therefore the message keeps showing up. how can I disable just that particular message? is there any option I may have missed in the settings?

thank you.

[olimorris]

Check the PR that added that notification. I included an option to disable

[coolapso]

Gott it! thanks a lot!

in case anyone stumbles here with the same question:

require("codecompanion").setup({
    ignore_warnings = true,
     ...
})

[cyanpencil]

Hi @olimorris,

Thank you for your quick reply;

You're absolutely right - my message was entitled and the tone was out of place.
I am sorry that my message was worded like an attack on you or your work. I do respect your work, and I still think it's the best nvim AI plugin.

I agree with you on the open-source side: you are the maintainer of the project and you're absolutely free to do whatever you want with it, and your users are not entitled to anything at all.

I hope that my shitty tone will not lead you to completely ignore the underlying message: design changes such as this are going to break people setups, which has the chance to drive users away from your plugin.
However, you seem to be already aware of this risk.

Btw, thanks for your tips on the deprecation warnings, I was not aware of those.
(Just to clarify: the deprecation was a minor nitpick; the breaking of the config and of the custom adapters I had was my main complaint).

I wish you the best of luck and success with CodeCompanion.

[olimorris]

No not at all and appreciate your sentiment, completely. We've all been on the end of plugin's breaking our config and it's time out of our day to fix something that we shouldn't have to. I do not want to be that maintainer 😆.

Regarding the adapters change for the ACP feature, I spent the majority of my time pondering how to incorporate them into CodeCompanion (the actual ACP implementation was easy). I don't think I had any breaking changes to adapters since v1.0.0 so wanted to be super careful this time around.

Could you share your custom adapters and how they broke? I'm keen to learn from that in the future.

[cyanpencil]

Hi @olimorris , sorry for replying so late, I was AFK the whole weekend.

What broke is the adapter detection in the inline strategy like :CodeCompanion <adapter> ..., it always fell back to the default adapter.

However, I took the time today to look into it and submitted a pr to fix it #2069 (sorry, I am super short in time and could not add tests... but the fix is pretty small and I tried manually that it works)

I'd like to apologize again for my tone earlier. I should have just gone and fixed it directly, instead of complaining.