Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request to create new release(s) for Go modules compatibility #39056

Closed
mcurtiss opened this issue Apr 10, 2019 · 25 comments
Closed

Request to create new release(s) for Go modules compatibility #39056

mcurtiss opened this issue Apr 10, 2019 · 25 comments

Comments

@mcurtiss
Copy link

Hey Folks,
I couldn't find this discussed elsewhere, so I'm asking here: Would it be possible to create a new release (and hopefully restart the process of creating regular new releases)?

Background: Apparently there hasn't been a new release since June 2017 (v17.03.2-ce). I wouldn't really care about this, except that the Go language is moving to adopt modules (i.e. versioned releases of packages), and go uses the latest github release as the default version of a module to fetch. So by not updating releases here (AFAICT), it makes it confusing (though not impossible) to use Go modules with moby.

More background/repro is in this golang issue I filed.

@faraazahmad
Copy link

would this be related to why i am unable to get get github.com/docker/docker/client?

@cpuguy83
Copy link
Member

Releases are handled through github.com/docker/engine currently.
You should target the branch/tag for the release you are wanting to support.

The other part of this is Docker does not follow semver, and while generally we do try to not break the package level API's it does happen from time to time.
This does not follow with the go modules method of versioning and will require manual management.

@faraazahmad
Copy link

faraazahmad commented Apr 16, 2019

So should I go get github.com/docker/engine ?

@monkeyWie
Copy link

monkeyWie commented Jul 22, 2019

Hey, do we have a solution now?

@ldez
Copy link

ldez commented Aug 4, 2019

As the go modules will become the default/standard for Go projects, is it Docker/Moby will reevaluate its versioning policy?

@cpuguy83
Copy link
Member

cpuguy83 commented Aug 4, 2019

Changing the versioning will not fix any problems caused by modules.
The fact that there are non-semver versions alone breaks automatic version selection.
That plus the fact that semver just does not make sense for the engine.

Having a library in a client lib in a separate repo which is semver kind of makes sense, but is hugely difficult to maintain.

For those wondering if there is a solution, yes! Use a "replace" directive and specify the docker/engine repo and tag that you want.

@ldez
Copy link

ldez commented Aug 4, 2019

the "replace" directive is not transitive (if a project depends of a lib that specify the replace directive, the replace will not apply to the project), so it's an unstable solution.

But I understand your point.

@ldez
Copy link

ldez commented Aug 4, 2019

Sorry to bother you, are you planning to replace the vendor.conf file with go.mod?
Even if you do not use semver.

@cpuguy83
Copy link
Member

cpuguy83 commented Feb 7, 2020

On the maintainers call today we discussed making client a dedicated module with its own tags (ie client/ will get its own go.mod and special tags client/) which, in theory, should work with go get.

@johanbrandhorst
Copy link

johanbrandhorst commented Apr 2, 2020

To users of go.dev and the official docker client, this versioning is very confusing: https://pkg.go.dev/github.com/docker/docker/client?tab=versions. Apparently the latest version it 1.13.1, while @master is currently detected as v1.4.2-0.20200331113714-bd81cf28590c. A separate module for the client would be greatly appreciated to fix this confusion.

@cpuguy83
Copy link
Member

cpuguy83 commented Apr 2, 2020

I'll bring this up again today. Really someone (a maintainer) just needs to do the work, but I'm definitely worried about breaking other consumers.
Basically, who are we going to break by making this change (I'm greater than 50% positive that it will break people)... is the number it will break higher or lower than the number of people currently feeling pain.

Another thing that is problematic is if we keep the current repo structure then we need 2 modules, one for api/types and one for client, and then we have to keep this things in sync somehow... or just move everything under a single package tree and break everyone.

@johanbrandhorst
Copy link

I think the majority of the Go ecosystem is getting behind modules (no evidence other than my own experience), and while that might certainly not be a majority of users right now, it will be sooner or later. I'm not sure how adding the module would risk breaking current users?

Another thing that is problematic is if we keep the current repo structure then we need 2 modules, one for api/types and one for client, and then we have to keep this things in sync somehow... or just move everything under a single package tree and break everyone.

Do they need to be kept in sync? If the dependency relationship is a simple arrow (one depends on the other), then it should be possible to version them independently. I'm by no means an expert, but it also should be possible to experiment a little (as long as you're not cutting any new releases imminently).

@leitzler
Copy link

leitzler commented Apr 2, 2020

Just to add some numbers to Johan’s comment (I hope you don’t mind): golang/go#38158 (comment). It looks indeed like quite a lot of the public repos have migrated to modules already!

@cpuguy83
Copy link
Member

cpuguy83 commented Apr 2, 2020

We don't use dep either, but also aren't using modules :)

@leitzler
Copy link

leitzler commented Apr 2, 2020

We don't use dep either, but also aren't using modules :)

I know, the comment include a lot of relevant numbers that can give a hint of modules adoption rate, regardless of earlier dependency management :)

@SimSmith
Copy link

SimSmith commented May 8, 2020

The Go Developer Survey 2019 also gives some additional numbers.
Among the respondents, 89% were using Go Modules.
https://blog.golang.org/survey2019-results

@RX14
Copy link

RX14 commented May 12, 2020

the "replace" workaround mentioned above doesn't seem to work with newer versions.

I tried adding replace github.com/docker/docker => github.com/docker/docker v19.03.8 but go changes this to replace github.com/docker/docker => github.com/docker/docker v17.12.0-ce-rc1.0.20200309214505-aa6a9891b09c+incompatible

@cpuguy83
Copy link
Member

Are you sure it's a problem? The first part of -aa6a9891b09c+incompatible is the commit for 19.03.8

@thaJeztah
Copy link
Member

The strange version is because go modules doesn't support release branches, and assumes releases are only done from master; it therefore finds a branch point on the master branch (and only those that it assumes are SemVer), and picks that as "the version" to use for generating a pseudo-version.

As @cpuguy83 explained, it's the commit (last part) that's the actual version that go mod uses

@rodrigocollavo
Copy link

FYI, the problem with go mod fetching v17.12.xxx instead of v19.03.xxx is related to the trailing zero not following semver compliance, that's why go fetches the nearest valid version (all v19 and v18 versions have a traling zero on the minor version number).

Is there any workaround for gomod? I'm not able to find a solution for this using go mod

@johanbrandhorst
Copy link

module xxx

go 1.14

require (
	github.com/docker/docker v1.4.2-0.20200213202729-31a86c4ab209
)

This version works for me. You might even be able to tweak it to a specific commit yourself.

@rodrigocollavo
Copy link

yes, but source code differs a lot from current master branch (19.x)

@thaJeztah
Copy link
Member

thaJeztah commented May 25, 2020

Specify the tag of the release you want to use in your go.mod, and go modules will pick the correct commit. It will show the confusing "pseudo version" but the commit will match.

Make sure to specify the version though, otherwise go modules will pick a very old version (v1.13.1), which it thinks is the current "stable" release. Here's a quick example;

mkdir foobar && cd foobar

Add a main.go

package main

import (
        "fmt"

        "github.com/docker/docker/api"
)

func main() {
       fmt.Println("the API version is", api.DefaultVersion)
}

Initialize your module;

go mod init foobar
# go: creating new go.mod: module foobar

Specify the version of docker/docker you want to use in your go.mod;

echo "require github.com/docker/docker v19.03.9" >> go.mod

Build the binary and verify that the correct API version is used. In this case, go downloads the module (the pseudo version it generates and downloads uses v17.12.0-ce-rc1, but the commit (811a247d06e8 matches v19.03.9: https://github.com/moby/moby/releases/tag/v19.03.9)

go build
# go: downloading github.com/docker/docker v17.12.0-ce-rc1.0.20200514230353-811a247d06e8+incompatible

./foobar
# the API version is 1.40

dhui added a commit to dhui/dktest that referenced this issue Sep 13, 2020
Addresses: #5
Ran `go get -u github.com/docker/docker@v19.03.12` per moby/moby#39056 (comment)
atavakoliyext added a commit to atavakoliyext/edward that referenced this issue May 26, 2021
Also bump the transitive github.com/docker/distribution dependency
to v2.7.0, based on the vendor.conf of github.com/docker/docker
at the above version. All other changes are due to `go mod tidy`.

This removes the dependency on github.com/Sirupsen/logrus, which is
the deprecated module name for github.com/sirupsen/logrus, the former
preventing projects that use bazel from using this repository, due
to the two modules' go_repository's resolving to the same name,
@com_github_sirupsen_logrus.

Note that v1.4.2-0.20200323100004-d8554bd58666 is the semver-compatible
pseudoversion for v17.09.1-ce, as the maintainers have opted out of
module version tagging (moby/moby#39056).
@yeukhon
Copy link

yeukhon commented Sep 30, 2022

If people still have this issue, just go to go.mod and update the version to whatever is found in https://pkg.go.dev/github.com/docker/docker/client?tab=versions (or whatever is latest in the release tag page).

Example:

github.com/docker/docker v20.10.18+incompatible

I am no expert so I don't know whether it is go.mod's architectural, intented limitation, or it is really the moby maintainer needing to comply with semver compliance. Well, I am using go 1.16, maybe this is a non-problem in a more modern version of Go shrug

@thaJeztah
Copy link
Member

not fully there yet, but at least the version format is more compatible (still needs +incompatible)

let me close this one for now

@thaJeztah thaJeztah closed this as not planned Won't fix, can't repro, duplicate, stale Sep 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests