dkulchenko / bunch

npm-like tool for managing Go dependencies
MIT License
79 stars 13 forks source link

non-repo packages are not versioned properly (unknown repo type) #22

Closed mberhault closed 9 years ago

mberhault commented 9 years ago

We're specifying packages that are not repos, and this seems to be causing problems for bunch.

Sample Bunchfile.lock line:

"github.com/awslabs/aws-sdk-go/service/ec2": "deaa78b60cfd55045252c52f4f7840c6d697c491",

bunch install output: (the interesting bit is at the end of the "setting version" line)

installing github.com/awslabs/aws-sdk-go/service/ec2 ... 
  - setting version of github.com/awslabs/aws-sdk-go/service/ec2 to  (resolved as deaa78b60cfd55045252c52f4f7840c6d697c491) ... skipped, unknown repo type
  - building package github.com/awslabs/aws-sdk-go/service/ec2 ... done
  - installing package github.com/awslabs/aws-sdk-go/service/ec2 ... done
successfully installed github.com/awslabs/aws-sdk-go/service/ec2

We're doing this a lot (full file), especially for things like the AWS SDK that have many parts we don't care about.

Please let me know if you need further information.

mberhault commented 9 years ago

CC: @tamird

mberhault commented 9 years ago

In setPackageVersion, I changed:

packageDir := path.Join(gopath, "src", getRealRepoPath(repo))

to:

packageDir, err := getPackageRootDir(repo)
if err != nil
...

And that did it. Not sure what the ramifications might be though.

tamird commented 9 years ago

Discussed in person: we think the solution here is to track the repo in Bunchfile.lock, not the full package path.

dkulchenko commented 9 years ago

@MBerhault, yep, that is the fix (with one minor tweak). d07244f should do it.