About dependencies' vendor folder

[kataras]

What version of Go (go version) and dep (git describe --tags) are you using?

Go: 1.9
dep: just installed from master

What dep command did you run?

dep init

Hello, could some one tell me if that is a bug or that's the expected behavior of dep init doesn't respects the vendor folder of the packages that is trying to install as dependencies? And if it's the expected behavior, are we sure that this is the best choice?

External, relative issues: https://github.com/kataras/iris/issues/731, flosch/pongo2#175

Thank you!

[carolynvs]

That is the expected behavior. dep doesn't use dependencies vendor directories to determine the appropriate version to use. What dep does do is check if your dependencies use dep, and if so, do its best to pick versions that meet every package's constraints. We also have an open issue (#821) to handle other tools configs, so that if for example one of your deps was using a supported tool like glide, dep would take that config into account as well.

Also dep will remove any vendor directory found in your dependencies when copying them to your vendor/, so that when you build, your dependencies are all using the same version of each package.

[kataras]

Thanks for answer @carolynvs , I can imagine the reasons behind it but that's not cool, the outcome result of go get is different than go dep even if running those at the same exact moment = unexpected behavior and may break a lot of applications in the future, I think the team should consider that.

Imagine that you're new gopher and go get x_repo_url, you see that it's working fine when you run your application with that dependency, after an hour you decide to use the dep init to put that x_repo_url in your application's vendor folder, you expect that will work as before, you did it in the same day, not months ago. The next day you run your app and you see failures, it's not easy to catch the reason behind those errors.

[sdboyer]

hi @kataras - it seems like you have some misconceptions about how dep is supposed to work.

nothing about dep is comparable to go get. that is by design. dep is a tool for managing the dependencies of your project - not a tool for someone else to fetch and install your project. in other words:

the outcome result of go get is different than go dep even if running those at the same exact moment

(go dep is not a command, so i'm going to guess this was intended to to be dep init)

of course it is - these are not supposed to be comparable. most importantly, dep init is not a command that you run repeatedly, in the same way that git init is a one-time deal. you use it to convert your project to management by dep. once that's done, dep ensure is the workhorse command that you run day-in and day-out.

even then, dep ensure -add isn't exactly comparable to go get. that is also by design.

but that's not cool

this is even less cool.

flattening all dependencies into the top-level vendor directory is the only really safe way of operating - it precludes the possibility of irreconcilable type errors, as well as the risks that come from duplicated state and logic from package-level vars and init funcs. flattening in this way entails stripping out nested vendor directories.

I think the team should consider that.

this is a foundational design decision for dep, stretching back well over a year. we've considered the options here extensively. i think you'll find, once you better understand the model, that the harms are not what you're currently imagining.

[kataras]

I know how go dep works... Really appreciated @sdboyer for giving a complete answer to that, new gophers know where to come now to learn about dependencies' dependencies.