Let me explain the thought process here.
The github repo name MUST have the name
go in it, and I believe should have also
sdk to make it clear that it’s only about the SDK and not a Go implementation of docker. A good counter example is
docker/cli which if you fork today to
username/cli has no information about what it actually is.
I asked Joffrey, the maintainer of
sdk, he said as long as it starts with
docker he doesn’t mind whether it’s
docker-py-sdk, hence my suggesting of
docker-sdk-go which is somewhat more idiomatic in the Go world, than
So far this is only for contributors to the SDK. Users would have a vanity URL at
golang.docker.io, and I thought
golang.docker.io/docker is the shortest and most straightforward URL. Again the majority of users won’t even see/care that it’s backed by github, so they wouldn’t see the mismatch between
If this mismatch is any weird, it is only to contributors, which although important, is not our primary concern with this project. Also, I asked around a bit, and what I got is:
- if possible avoid “last part of import path” being different from package name, so let’s avoid an import path ending with
/go-docker (or even worse
/docker-sdk-go) hosting a package named
/docker-sdk-go with a package named
docker is more confusing for users than the
/docker-sdk-go mismatch for contributors.
I will try to test this conclusion with more people outside docker.
Another important note: as a user, if you don’t know what package name to use when importing a URL, you can’t use
goimports to automatically detect it for you (as I previously thought), because you first have to use the package otherwise goimports removes the import line. Another point to prioritize the user over the contributor.
Hope this helps clarify.