Optional dependencies in module

[Arnaud Delobelle]

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

[Manlio Perillo]

On Tuesday, February 8, 2022 at 6:22:14 PM UTC+1 arn...@gmail.com wrote:

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:

Note that a single repository can have multiple modules, so you can make cmd/golua-repls a separate module, adding github.com/arnodel/golua as a dependency.

See https://go.dev/ref/mod#vcs-version.

> [...] 

Manlio

[Arnaud Delobelle]

On Tue, 8 Feb 2022 at 20:55, Manlio Perillo <manlio....@gmail.com> wrote:

> Note that a single repository can have multiple modules, so you can make cmd/golua-repls a separate module, adding github.com/arnodel/golua as a dependency.
> See https://go.dev/ref/mod#vcs-version.

That is good to know! My question was relayed on Gophers slack
(https://gophers.slack.com/archives/C0VPK4Z5E/p1644352629693789) and
there was some good advice. What I took from it was that the best
approach is probably a single module in a single repo with a clear
message in the README explaining that the "core" packages have no
external dependencies so that people browsing the module have less
chance of being misled by the contents of go.mod

Cheers,

--
Arnaud