Godep is removing nested Godeps

[aanm]

I'm importing a project that has a Godep directory.

foo
  - Godeps/

however it seems like godep is removing that directory (foo/Godeps) when I use godep save -r ./... in my own project, is this the expected behavior?

[freeformz]

Yes. It should flatten those deps out.

[aanm]

@freeformz But this is bad if 2 projects that I'm importing use 2 different version of a 3rd project. For example

foo
  - Godeps/a/v1
bar
  - Godeps/a/v2

[freeformz]

yes, we should do better there. There are also all sorts of problem related to v1 and v2 of "a" being used at the same time. For instance a type from v1 of "a" is not the same as the same type returned from v2 of "a". Even if they look the same. The only sane thing to do is flatten. We should ask / prompt / let the user decide which one to choose though (assuming we can't programmatically determine the best version).

[aanm]

But why can't godep store both Godeps in the final result?

final
  - Godeps/foo/Godeps/a/v1
  - Godeps/bar/Godeps/a/v2
 #and if final is directly using 'a', then also
  - Godeps/a

[freeformz]

Because there would then be 3 versions of the same dep. That can lead to confusing, unexpected and subtle errors in the program.

[aanm]

Why? foo will only use the deps inside its own Godeps/, bar would do the same and so on.

foo would have

import "github.com/foo/Godeps/a/v1"

bar would have

import "github.com/bar/Godeps/a/v2"

[freeformz]

if foo and bar happen to return their own a types to their users they won't be equal if compared, which can lead to issues. I don't have links handy but this has been discussed a bunch in Go issues and IIRC go-nuts.

[aanm]

Ah got it... Thanks for the explanation, yes it is difficult that way...