Switch from Glide to Dep

[NeoCN]

Is there any plan to switch Go dependency management tool from Glide to Dep?

Dep announced that it is safe for production use. see https://github.com/golang/dep#current-status

And the Glide project is suggesting users consider trying to migrate from Glide to dep. see https://github.com/Masterminds/glide#golang-dep

Glide will continue to be supported for some time but is considered to be in a state of support rather than active feature development.

[vprithvi]

I haven't used Dep yet, but if the UX of Dep is better than glide I don't see a reason not to.
(The graphviz diagrams look really useful)

[frankgreco]

I can work on this. I just finished migrating to dep from glide for another project and so while everything is still fresh I can tackle this.

[yurishkuro]

I prefer not to rush to dep, which is only at v0.3. There is no major upside from this migration yet, but there is a big downside because dep can import glide config, but not vice versa. We internally build with a different main, so we need to import oss jaeger, but our build system is based on Glide, so switching oss jaeger to dep will create issues.

Once Jaeger dependencies start switching to dep then this upgrade will become more relevant.

[vprithvi]

There is no major upside from this migration yet,

I disagree, I find deps UX significantly better, it has the following features that glide lacks

• Updating a single dependency
• Visualizing dependencies
• Listing out the latest version of dependencies without having to update them

switching oss jaeger to dep will create issues.

Do you have evidence for this claim?

The glide documentation does not say that all dependencies need to be using glide. (If they are, glide reads the project's glide.yaml, but if it isn't, it just scans imports).

Glide scans the source code of your application or library to determine the needed dependencies. To determine the versions and locations (such as aliases for forks) Glide reads a glide.yaml file with the rules. With this information Glide retrieves needed dependencies.

When a dependent package is encountered its imports are scanned to determine dependencies of dependencies (transitive dependencies).

[yurishkuro]

Do you have evidence for this claim?

You said it yourself, "if it isn't, it just scans imports" - that means no semver versioning or even pinned dependencies like the gocql driver.

[dstroot]

Yuri - I started using Glide and have switched to Dep because it has momentum behind it. Both work well and I agree no need to rush. I think your view that you can't have pinned dependencies is incorrect. The Gopkg.toml file is used for that purpose. It looks like this example:

# Gopkg.toml example
#
# Refer to https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md
# for detailed Gopkg.toml documentation.
#
# required = ["github.com/user/thing/cmd/thing"]
# ignored = ["github.com/user/project/pkgX", "bitbucket.org/user/project/pkgA/pkgY"]
#
# [[constraint]]
#   name = "github.com/user/project"
#   version = "1.0.0"
#
# [[constraint]]
#   name = "github.com/user/project2"
#   branch = "dev"
#   source = "github.com/myfork/project2"
#
# [[override]]
#  name = "github.com/x/y"
#  version = "2.4.0"


[[constraint]]
  name = "github.com/dstroot/utility"
  version = "1.1.0"

[[constraint]]
  name = "github.com/julienschmidt/httprouter"
  version = "1.1.0"

[[constraint]]
  branch = "master"
  name = "github.com/oxtoacart/bpool"

[[constraint]]
  name = "github.com/pkg/errors"
  version = "0.8.0"

[[constraint]]
  name = "github.com/prometheus/client_golang"
  version = "0.8.0"

[[constraint]]
  name = "github.com/urfave/negroni"
  version = "0.3.0"

[yurishkuro]

I meant that you cannot have pinned transitive dependencies. For example, this depedency chain: uber[glide] -> jaeger[dep] -> gocql[pinned]. Jaeger pins gocql driver, but because it uses dep, when it's imported by an uber project using glide, glide will not read jaeger/Gopkg.toml, instead it will find all imports in jaeger and try to import their latest versions. Thus whichever pins exist in jaeger/Gopkg.toml will not be respected by glide above.

Again, I am not saying that we should not switch to dep ever, I'm saying that right now it will cause more headache than benefits. We can revisit in 2-3 months.

[margic]

Is there any advice on how to use jaeger with a dep project.

Get a bunch of these kinds of errors

../vendor/github.com/uber/jaeger-client-go/thrift-gen/jaeger/agent.go:101:34: cannot use agentProcessorEmitBatch literal (type *agentProcessorEmitBatch) as type thrift.TProcessorFunction in assignment:
        *agentProcessorEmitBatch does not implement thrift.TProcessorFunction (wrong type for Process method)
                have Process(int32, thrift.TProtocol, thrift.TProtocol) (bool, thrift.TException)
                want Process(context.Context, int32, thrift.TProtocol, thrift.TProtocol) (bool, thrift.TException)
../vendor/github.com/uber/jaeger-client-go/thrift-gen/jaeger/agent.go:111:27: not enough arguments in call to processor.Process
        have (int32, thrift.TProtocol, thrift.TProtocol)
        want (context.Context, int32, thrift.TProtocol, thrift.TProtocol)

[yurishkuro]

I have switched the tutorial to dep: https://github.com/yurishkuro/opentracing-tutorial

[jpkrohling]

This has been completed, right?

[yurishkuro]

Solved by #1240