What is the role of try.nvim?

[mjlbach]

This started as a "let me create an immutable environment for good bug reports" which informed the choice of what to put into the container. Some remaining questions:

• Should the container drop you directly into neovim? Directly into a file?
• Should the container contain a single example project, or should we encourage users to bind mount their own
• Should the configs be "optimal" for the language (include rust-tools for example) or minimal to encourage clean bug reports?

cc @clason @dundargoc.

[clason]

I think you can't have both ("minimal" config for bug reports and "optimal" config for users), and trying to straddle the divide is something I'd leave to Jean-Claude Vandamme.

Suggestion (extended from chat):

1. in try.nvim have minimal (functional) configs for testing and bug reports; ideally for each language (server) supported by lspconfig.
2. add a try-contrib.nvim repo for user-contributed extended ("optimal") configs for each language.

These could default to different behavior (e.g., only the latter dumps you directly into neovim as a sort of "super appimage"). The big question is how to link them so improvements to the "base" container also apply to the "extended" container (and, of course, how much quality control to apply).

[mjlbach]

I think try.nvim base containers should include an example project, and should drop you into bash (in the root of the example project)

I think contrib can be whatever the user wants, generally following the kickstart template, with some room for additional off-spec support

[lockejan]

I would like to encourage users to mount in their specific project. At least give them the necessary information to do so.

However, in this case we should also inform about potential consequences, e.g. the container user would write to their local file system, etc...

[dundargoc]

I don't really see the connection between reproducible bug reports and language-demo to be strong enough to justify them being in the same repository/project other than that they both use containers (maybe that's good enough?). If I were to prioritize then I think the bug reporting sounds more valuable but I haven't thought much about this so I appreciate your thoughts.

Should the container drop you directly into neovim? Directly into a file?

No strong preference either way. We can experiment with this and see what we like most.

Should the container contain a single example project, or should we encourage users to bind mount their own

I'm having trouble understanding the benefit of the user mounting their own project. Why would it be more beneficial to do so?

Should the configs be "optimal" for the language (include rust-tools for example) or minimal to encourage clean bug reports?

I'd probably err on the minimal side to start with. Ideally, and you were the one who pitched the idea to me first, we would have different "levels" of config to better pinpoint the cause. Level 1 would be base neovim (--clean perhaps?), level 2 would be a minimal config with carefully curated plugins and level 3 would be the users own config or something along those lines. Not sure how feasible this is to implement but I liked it when you pitched it to me at least :).

[lockejan]

Should the container contain a single example project, or should we encourage users to bind mount their own

I'm having trouble understanding the benefit of the user mounting their own project. Why would it be more beneficial to do so?

Hmm, probably a matter of preference. Initially I would go for just trying out the example project. But depending on my project specifics I can see myself wanting to do the same with it as well. Just to make sure that any additional stuff isn't interfering. Like additional external tools, project setups, ... At least that was my initial journey with try.nvim, but I can't speak for everyone.

[lockejan]

I can see both use cases, but like dundargoc I see a higher value in reproducible bug reports.

• Should the configs be "optimal" for the language (include rust-tools for example) or minimal to encourage clean bug reports?

I prefer having a minimal setup first to support the bug reporting. That's an MVP we can iterate over and see if it's sufficient already and solves a problem at all.

If the answer is yes, I would continue to implement clason suggestion:

2. add a try-contrib.nvim repo for user-contributed extended ("optimal") configs for each language.

These could default to different behavior (e.g., only the latter dumps you directly into neovim as a sort of "super appimage"). The big question is how to link them so improvements to the "base" container also apply to the "extended" container (and, of course, how much quality control to apply).

I don't see a problem in including more variations in our CI and having several repos ( probably as submodules). Maybe even for the minimal images. The only downside is that CI will probably take ages to finish.

[mjlbach]

My thoughts after a day (not definitive)

Should the container drop you directly into neovim? Directly into a file?

I think no, it should drop you into a shell

Should the container contain a single example project, or should we encourage users to bind mount their own

Yes, it should contain a single example project, pre-compiled if necessary.

Should the configs be "optimal" for the language (include rust-tools for example) or minimal to encourage clean bug reports?

They should be kickstart.nvim + the minimal necessary to use LSP. Preferably lspconfig, but perhaps with rare exceptions (nvim-jdtls) not.

I don't see a problem in including more variations in our CI and having several repos ( probably as submodules). Maybe even for the minimal images. The only downside is that CI will probably take ages to finish.

I wouldn't worry about CI, we can always get a dedicated builder.

[mjlbach]

I've standardized on dropping you into a shell, with a single example project.