The issue is that the vim-go packages are not compatible with all go versions, so some of them are better handled like project dependencies instead of editor deps. I have a project using unstable pkgs and ran into this problem there. Since this was a private personal project, I just made my nvim config an input that followed the same pkgs to get around the issue.
There are some problems with this, though. Many of my vim plugins will be on newer versions because of this and are at risk of encountering breaking changes.
Options:
Different inputs for packages and plugins?
Could even have didn't inputs for groups of related packages
Provide required binaries in project dev shells
Option 1 has the same issue that for project that should be worked on by multiple people it doesn't make sense for me to put my editor into the dev env.
Option 2 still involves my editor configuration bleeding into a shared dev shell. Not as bad as my entire editor, though. It would also be a bit annoying to always have to include these in every project, even though vim-go packages may work on most projects I develop on.
There is another way that comes to mind. I could build two version of my editor. One that excludes potentially project specific packages, and one that includes all packages. Then I could just decide on the fly which to use. This could make sense in combination with option 2.
The issue is that the vim-go packages are not compatible with all go versions, so some of them are better handled like project dependencies instead of editor deps. I have a project using unstable pkgs and ran into this problem there. Since this was a private personal project, I just made my nvim config an input that followed the same pkgs to get around the issue.
There are some problems with this, though. Many of my vim plugins will be on newer versions because of this and are at risk of encountering breaking changes.
Options:
Option 1 has the same issue that for project that should be worked on by multiple people it doesn't make sense for me to put my editor into the dev env.
Option 2 still involves my editor configuration bleeding into a shared dev shell. Not as bad as my entire editor, though. It would also be a bit annoying to always have to include these in every project, even though vim-go packages may work on most projects I develop on.
There is another way that comes to mind. I could build two version of my editor. One that excludes potentially project specific packages, and one that includes all packages. Then I could just decide on the fly which to use. This could make sense in combination with option 2.