go modules multiple main methods

Question

I have a project with mutliple main methods. When running go build program1/main1.go which has a different set of dependencies than program2/main2.go, my first go build seems to alter my go.mod file and removes the dependencies it thinks it does not need. Yet main2 would need these dependencies.

I've tried using go build ... but that also created a different set of dependencies. Specifically, it seems like all the //indirect dependencies get removed and cause program2 to fail.

Is there a way of running go build or go run without updating the go.mod file? Using go build -mod=readonly program1/main1.go it tells me that it fails because the dependencies need to be updated..

Qp

If two things do not have the same dependencies and each should have it's own go.mod. The go.mod contains the dependencies and not just some (read "unrelated", "old", and "copy-past-leftovers") dependencies. – Mendymene

Your life will be much simpler if you able to only working with one module at a time, so you don't want to needlessly cut up what could be a single module. If you do split them out into separate modules with individual go.mod files, it is more work. That said, there is an overview of the new Go 1.18 workspace feature in this answer. Workspaces make it easier to handle editing multiple modules at once. Separately, this answer here has a good overview of how to organize a module in general. – Wreckful

Answer 1

I believe you're looking for submodules. See this walktrhough.

TLDR: you'll want a separate go.mod in each of your tools's cmd dir, and you can use the replace directive to point dependncies from these tools to your local module.

This Go Issue and others linked from it suggest that figuring out "the one right way" to do this is still WIP, though I think your use case is simple enough.

Photophilous

Yeah, eventually that's what I did :) Thanks! – Qp

Answer 2

Using submodules is a way to nest multiple Go module projects you can edit.

But Go 1.18 might include the notion of Go workspace, which means you don't need submodules anymore: one Go project can include multiple modules you can edit.

See golang/go issue 45713: "proposal: cmd/go: add a workspace mode " and its design document.

Background

Users often want to make changes across multiple modules: for instance, to introduce a new interface in a package in one module along with a usage of that interface in another module.

Normally, the go command recognizes a single "main" module the user can edit.
Other modules are read-only and are loaded from the module cache.

The go mod replace directive is the exception: it allows users to replace the resolved version of a module with a working version on disk.
But working with the replace directive can often be awkward: each module developer might have working versions at different location on disk, so having the directive in a file that needs to be distributed with the module isn't a good fit for all use cases.

Proposal

This proposal describes a new workspace mode in the go command for editing multiple modules.

The presence of a go.work file in the working directory or a containing directory will put the go command into workspace mode.
The go.work file specifies a set of local modules that comprise a workspace. When invoked in workspace mode, the go command will always select these modules and a consistent set of dependencies.

Main modules: The module the user is working in.
Before this proposal, this is the single module containing the directory where the go command is invoked. This module is used as the starting point when running MVS.
This proposal proposes allowing multiple main modules.

See for instance CL 334934 (CL = Change List)

[dev.cmdgo] cmd/go: add the workspace mode

This change adds the outline of the implementation of the workspace mode.

The go command will now locate go.work files, and read them to determine which modules are in the workspace.
It will then put those modules in the root of the workspace when building the build list.
It supports building, running, testing, and listing in workspaces.

You can initiate a multiple-module project with go mod initwork

Again, this is not before Go 1.18 (Q1 2022) and will probably be opt-in in Go 1.19 (Q3 2022).

Panpsychist