Hi all, Here is my issue: I have a Go module at github.com/arnodel/golua which implements a Lua compiler / runtime. It has no external dependencies (strictly, there is a dependency on another small module of mine implementing strftime) and that is easily verifiable by looking at the go.mod file. As a typical usage of Lua is to embed it into another program, it is important to me that it is clear that there are no dependencies brought in when doing that.
On the other had, I want to add a REPL command which will have a dependency on a third party terminal management package (https://github.com/gdamore/tcell) because it would be silly of me to reimplement that! This REPL is completely optional. The simplest solution I see is to add a `cmd/golua-repl` package to my module implementing the REPL. Why it seems the right solution: + It is nice because installing the REPL at a given version of the module will always use the Lua VM for the same version. + No need to have two repositories, two modules and keep dependencies up to date. That would create a confusing situation for me and for users. + Because of dependency pruning, I believe that users who e.g. want to embed the Lua runtime into their program will not download the extra REPL dependencies, because the runtime package doesn't actually import them (as long as they use recent Go). OTOH - The go.mod file of my golua module will now show the extra dependency and its dependencies. This will make it much less evident to users that those dependencies are not applicable to the golua runtime packages. To me this feels like a big negative point and it makes me very hesitant to take this approach. So I would like to ask for some wisdom on this problem. - Am I overstating the problem? - Are there good mitigations that people know work? - Is there another simple approach that would keep go.mod of my module clean? As stated above, I don't think two repositories with a golua module and a golua-repl module are very attractive solutions, and it seems that having two modules in one repository is not a very good approach either. And these are the only other approaches I can think of. Thanks in advance, Arnaud Delobelle -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAJ6cK1Z%3DyD_dBLYueH8d%3DudGkiTpSz29LesDqc5-K8a9ws2e-Q%40mail.gmail.com.
