search

tools / godep

dependency tool for go
http://godoc.org/github.com/tools/godep
BSD 3-Clause "New" or "Revised" License
5.54k stars 455 forks source link

Godep forces to vendor redundant packages #466

Closed kowalczykp closed 8 years ago

kowalczykp commented 8 years ago

It happens quite often that, while introducing vendor via godep into a new project it comes with lot's of pain, because godep is hungry for all the dependencies of project's original dependencies, done in an recursive way.

This leads to a situation, that even through the project builds (meaning, it has all the required dependencies in the GOPATH) godep fails with "package X not found" error while attempting to save.

Obviously this can be softened by proper loose coupling between the packages, but my expectation of a vendor tool is to choose packages for vendoring exactly the same way as go get does for putting them into GOPATH, meaning only necessary packages for compilation. The less we vendor, the less we have to update in future.

freeformz commented 8 years ago

godep and go get can't work the same way. go get only pulls dependencies for the current architecture. godep needs to get all dependencies, across all OS, so that when a developer is working on OS Y the code can be deployed to OS Z. This is pretty common (I for one do most development on OSX, but most deployments to Linux).

I do plan to add a field to Godeps.json to either blacklist or whitelist OS / build tags, but that is not done yet.

kowalczykp commented 8 years ago

This is not concerning the architecture at all, I can try to create a simple repro.

Basically: Given a dependency of packageX in RepoX, go get stops at this point while downloading/requiring dependencies, while godep save requires all the dependencies from RepoX to be existient in the GOPATH before godep save

freeformz commented 8 years ago

go get will also fetch any missing dependencies required to build packageX. This is the same as godep. godep will only scan dependencies for packages required by the package spec provided to godep save.

What version of godep are you using? Older versions of godep were more "liberal".

kowalczykp commented 8 years ago

I'm using the newest godep, and it seems that it is indeed working as intended, what has mislead me, was vendored dependencies inside my project's original dependencies.

Godep enforces to flatten those dependencies, and this is approach I support in 100% (that's why we chose godep in the first place), but I somehow managed to misinterpret the additional dependencies enforcement while saving ;)

Current approach concerning OS tags is wise as well, as I am regulary switching between mac<->linux myself, although adding f.e. windows to blacklist tags in godeps, would be awesome, especially for internal/commercial projects. Looking forward to that feature.

Thanks