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

Use go mod #2314

Merged
merged 20 commits into from
Aug 14, 2019
Merged

Use go mod #2314

merged 20 commits into from
Aug 14, 2019

Conversation

wxing1292
Copy link
Contributor

@wxing1292 wxing1292 commented Jul 30, 2019

  • Modify Makefile accordingly

After this PR is landed, Cadence repo can live at anywhere.
For development, please move the Cadence repo out of GOPATH

* Modify Docker files and Makefile accordingly
@wxing1292 wxing1292 reopened this Jul 30, 2019
@shreyassrivatsan
Copy link
Contributor

let's land this after you are back..

@wxing1292
Copy link
Contributor Author

let's land this after you are back..

sure

@h7kanna h7kanna mentioned this pull request Aug 1, 2019
Makefile Outdated
dep ensure
go-mod:
go mod tidy
go mod vendor
Copy link
Contributor

Choose a reason for hiding this comment

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

This is only necessary if you want to vendor dependencies and commit the vendor directory. Since you are not doing it with dep, I'm guessing you don't really need it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ah, that is true, previously the yarpc was using something from vendor dir

yarpc-install:
	go get './vendor/go.uber.org/thriftrw'
	go get './vendor/go.uber.org/yarpc/encoding/thrift/thriftrw-plugin-yarpc'

basically the orioginal code was trying to use the same version of thriftrw and thriftrw-plugin-yarpc for code generation.

the thing is, go get './vendor/go.uber.org/thriftrw' can work
however go get './vendor/go.uber.org/yarpc/encoding/thrift/thriftrw-plugin-yarpc' cannot, due to missing dir (probably due to something similar to golang/go#32504).

any suggestion?

Copy link
Contributor

Choose a reason for hiding this comment

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

If you want to make sure that the same version is used for both libraries, you should probably use the replace directive

Copy link
Contributor Author

Choose a reason for hiding this comment

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

that is not what I meant, not version control.

the thriftrw and thriftrw-plugin-yarpc are both tool dependency, and previously go.uber.org/yarpc/encoding/thrift/thriftrw-plugin-yarpc cannot be successfully imported due to it being a main package

I think the correct solution is tools dependency

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, okay, got it.

I would consider using a tool like gobin then. (I'm personally not a huge fan of the tool dependency pattern)

Here is an example: https://github.com/sagikazarmark/modern-go-application/blob/master/Makefile#L186-L202

Makefile Outdated
./install-dep.sh
dep ensure
go-mod:
go mod tidy
Copy link
Contributor

Choose a reason for hiding this comment

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

Go modules are installed automatically when you run go build or go test. There is no need to run tidy every time.

Makefile Outdated

yarpc-install:
go get './vendor/go.uber.org/thriftrw'
go get './vendor/go.uber.org/yarpc/encoding/thrift/thriftrw-plugin-yarpc'
go get 'go.uber.org/thriftrw'
Copy link
Contributor

Choose a reason for hiding this comment

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

FYI This will actually update the dependencies to their latest version every time you run this.

Makefile Outdated
@@ -97,38 +97,38 @@ thriftc: yarpc-install $(THRIFTRW_GEN_SRC)
copyright: cmd/tools/copyright/licensegen.go
GOOS= GOARCH= go run ./cmd/tools/copyright/licensegen.go --verifyOnly

cadence-cassandra-tool: dep-ensured $(TOOLS_SRC)
cadence-cassandra-tool: go-mod $(TOOLS_SRC)
Copy link
Contributor

Choose a reason for hiding this comment

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

As said above, go-mod is not necessary here.

WORKDIR /go/src/github.com/uber/cadence

RUN curl https://raw.githubusercontent.com/golang/dep/master/install.sh | INSTALL_DIRECTORY=/usr/local/bin sh
COPY Gopkg.* ./
Copy link
Contributor

Choose a reason for hiding this comment

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

This should be replaced with go.* copied into the image and go mod download ran in order to build an image cache.

Here is a snippet from our Dockerfile:

ENV GOFLAGS="-mod=readonly"
ARG GOPROXY

COPY go.* .
RUN go mod download

The readonly flag makes sure that no new dependencies are installed, thus making sure that there are no surprises around dependencies.

The GOPROXY arg allows using a go modules proxy. It's optional, but allows a developers to build an image with a proxy.

Copy link
Contributor Author

@wxing1292 wxing1292 Aug 3, 2019

Choose a reason for hiding this comment

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

thanks for pointing out, the ENV GOFLAGS="-mod=readonly" and ARG GOPROXY are added.

just 2 questions

  1. on line 10 there is a COPY . ., which should already copy the go.mod and go.sum?
  2. why go mod download? I tested building the docker image locally, and it seems working.

Copy link
Contributor

Choose a reason for hiding this comment

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

In order to utilize the docker build cache, it's a best practice to place things at the beginning of the build that has the least chance to change.

In this case, by downloading dependencies separately first you can spare some time with the build when only the code changes, but not the list of dependencies (which is usually the case).

Otherwise every time something changes, you would have to download the dependencies (which takes time) even if they haven't actually changed.

Although this does not add much in a build environment (if you can't utilize the build cache), it's really helpful when building locally. It doesn't take more time to build the image this way, so this kind of optimization usually make sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i see

Dockerfile Outdated
@@ -79,7 +74,7 @@ CMD /start.sh
# Cadence CLI
FROM alpine AS cadence-cli

COPY --from=builder /go/src/github.com/uber/cadence/cadence /usr/local/bin
COPY --from=builder /cadence /usr/local/bin
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
COPY --from=builder /cadence /usr/local/bin
COPY --from=builder /cadence/cadence /usr/local/bin

yarpc-install:
go mod vendor
Copy link
Contributor

Choose a reason for hiding this comment

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

I still think using gobin would be better here. In the same issue that you linked eariler (golang/go#32504) it seems to me that some tooling will be the final solution eventually, not tools.go.

Copy link
Contributor Author

@wxing1292 wxing1292 Aug 3, 2019

Choose a reason for hiding this comment

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

for this issue, I need some opinion from my colleagues @shreyassrivatsan @samarabbas @dmetzgar, any idea?

basically, from my understanding, we can either use the following to ensure using the same version defined in go.mod for thriftrw and thriftrw-plugin-yarpc

yarpc-install:
	go mod vendor
	go get './vendor/go.uber.org/thriftrw'
	go get './vendor/go.uber.org/yarpc/encoding/thrift/thriftrw-plugin-yarpc'

or using gobin which will do the same, i.e. use the same version thriftrw and thriftrw-plugin-yarpc defined in go.mod

FYI, this PR will not be landed until I get back, which is roughly 1 week later.
In the meantime, I will try to do some investigation

Copy link
Contributor

Choose a reason for hiding this comment

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

By using gobin, those two tools won't be added to go.mod which means less dependencies. Also, you don't need go mod vendor.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

By using gobin, those two tools won't be added to go.mod which means less dependencies. Also, you don't need go mod vendor.

for our use case, we prefer to use the binary from dependency go.uber.org/thriftrw and go.uber.org/yarpc (we are already depending on these 2 lib).
assuming that my understanding of gobin is correct (ref), tool dependency still needs to be declared.

so (still assuming that my understanding is correct) the difference is basically whether it is a good idea to include another dependency.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, okay. If they are library dependencies as well, I guess this solution is ok.

@@ -30,5 +30,5 @@ RUN go get golang.org/x/tools/cmd/cover

# The golang Docker sets the $GOPATH to be /go
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm guessing this comment doesn't really make sense anymore.

@wxing1292 wxing1292 merged commit dcef9dc into master Aug 14, 2019
@wxing1292 wxing1292 deleted the go-mod branch August 14, 2019 17:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants