Skip to content

[carry 4116] switch to go module - #7299

Open
AkihiroSuda wants to merge 5 commits into
docker:masterfrom
AkihiroSuda:go-mod
Open

[carry 4116] switch to go module#7299
AkihiroSuda wants to merge 5 commits into
docker:masterfrom
AkihiroSuda:go-mod

Conversation

@AkihiroSuda

@AkihiroSuda AkihiroSuda commented Sep 11, 2026

Copy link
Copy Markdown
Collaborator

- What I did
Carry:

- How I did it

Asked Claude to carry #4116 and reviewed the result

- How to verify it

make -f docker.Makefile binary

- Human readable description for the release notes

switch to go module

- A picture of a cute animal (not mandatory but encouraged)

crazy-max and others added 5 commits September 12, 2026 01:31
@crazy-max @AkihiroSuda
switch to go module
53c9234 
Rename vendor.mod/vendor.sum to go.mod/go.sum, making this repository
a proper Go module.

This removes the machinery that was needed to work around the absence
of a go.mod:

- scripts/with-go-mod.sh, which symlinked vendor.mod/vendor.sum into
  place for commands that require a module;
- the equivalent symlink dances in the CodeQL and test workflows, and
  in Dockerfile.lint;
- the "GO111MODULE=auto" overrides in the Makefile, build scripts, and
  Dockerfiles;
- internal/gocompat, which verified that our packages are consumable in
  module mode. With a real go.mod, the "go" directive sets the language
  version for all packages in the module, so the "//go:build go1.xx"
  workaround it guarded is no longer needed.

Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
@AkihiroSuda
cmd/docker-trust: stop importing the root module's internal packages
dc03093 
The "docker-trust" plugin lives in a nested module, and reaches into
the root module's "internal/" packages. That works today because its
module path ("github.com/docker/cli/cmd/docker-trust") is a prefix
match for "github.com/docker/cli/internal/...".

Once the root module gains a major-version suffix, the internal path
becomes "github.com/docker/cli/v29/internal/...", which the nested
module is no longer allowed to import ("use of internal package ...
not allowed").

Folding the plugin back into the root module is not an option: notary
and its dependencies pull in ~45 additional modules (MySQL, SQLite,
bugsnag, gorm, ...) which is exactly why it was split out.

So copy the four small helpers it uses into the plugin's own internal
tree instead.

Assisted-by: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
@crazy-max @AkihiroSuda
update import paths to v29
6f89ea1 
Go modules require a major-version suffix in the module path for
major versions >= 2, so the module becomes "github.com/docker/cli/v29"
and all import paths are updated accordingly.

Note that this means the import paths have to be updated on every
major (CalVer) bump of the CLI.

Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
@crazy-max @AkihiroSuda
GOPATH handling not necessary anymore
cca7469 
The repository is a Go module now, so the test workflow no longer has
to check out into a GOPATH-shaped directory.

The remaining GOPATH use in scripts/test/e2e/run is unrelated: the e2e
suite installs a test plugin into $GOPATH/bin.

Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
@AkihiroSuda
remove "//go:build go1.26" workarounds
842eec8 
These were added because the repository was not a module: consumers
got an implicitly generated go.mod, which made go assume the "go1.16"
language version and reject any newer language feature. The "//go:build"
directive overrode the language version on a per-file basis.

Now that there is a real go.mod, its "go" directive sets the language
version for every file in the module, so the workaround can go, as the
FIXME they carried asked for.

Assisted-by: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
@AkihiroSuda
AkihiroSuda requested review from a team and thaJeztah as code owners September 11, 2026 16:38
@AkihiroSuda AkihiroSuda added the area/go-sdk Changes affecting the Go SDK label Sep 11, 2026
@AkihiroSuda AkihiroSuda added the impact/go-sdk Noteworthy (compatibility changes) in the Go SDK label Sep 11, 2026
@AkihiroSuda AkihiroSuda added this to the v-future milestone Sep 11, 2026
@codecov-commenter

codecov-commenter commented Sep 11, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

AkihiroSuda
AkihiroSuda commented Sep 11, 2026
View reviewed changes
Comment thread go.mod
// 'vendor.mod' enables use of 'go mod vendor' to managed 'vendor/' directory.
// There is no 'go.mod' file, as that would imply opting in for all the rules
// around SemVer, which this repo cannot abide by as it uses CalVer.
module github.com/docker/cli/v29

@AkihiroSuda AkihiroSuda Sep 11, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Possibly this should be bumped up to v30?)

This was referenced Sep 11, 2026
Draft
Draft
Draft
@AkihiroSuda

AkihiroSuda commented Sep 11, 2026

Copy link
Copy Markdown
Collaborator Author

Thanks, looks hopeful (so far). FWIW; I was discussing this briefly in the maintainers call, and I think the initial response was to "Let's do both Moby and CLI at the same time". I'm personally partial to either (same time, or separately), but before we make the decision and plunge in, we should;

  • Do some testing / verification to see if there's other pain-points where we may be painting ourselves into a corner (more below)
  • Document the steps (and order / "sequence of steps") what to do when preparing a new release. The intent currently is to bump the "major" version fo every release, which means we will "rename the module" for every (non-patch) release

[...]

From the above, I wonder if we need to create test-PRs that;

  1. update buildkit to use this PR (and perhaps even update moby to use that)
  2. update buildx to use this PR (and 1?)
  3. update compose to use this PR (and 2?)

Originally posted by @thaJeztah in #4116 (comment)

Submitted test PRs:

@AkihiroSuda AkihiroSuda mentioned this pull request Sep 11, 2026
Closed
@AkihiroSuda AkihiroSuda linked an issue Sep 11, 2026 that may be closed by this pull request
Move to go modules based build #2905
Open
@AkihiroSuda AkihiroSuda mentioned this pull request Sep 11, 2026
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@thaJeztah thaJeztah Awaiting requested review from thaJeztah thaJeztah is a code owner
@silvin-lubecki silvin-lubecki Awaiting requested review from silvin-lubecki silvin-lubecki is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

area/go-sdk Changes affecting the Go SDK impact/changelog impact/go-sdk Noteworthy (compatibility changes) in the Go SDK kind/enhancement

Projects

None yet

Milestone

v-future

Development

Successfully merging this pull request may close these issues.

Move to go modules based build

3 participants

@AkihiroSuda @codecov-commenter @crazy-max