search

golang / dep

Go dependency management tool experiment (deprecated)
https://golang.github.io/dep/
BSD 3-Clause "New" or "Revised" License
12.87k stars 1.05k forks source link

dep init deletes vendor folder and breaks build instead of using it for a working baseline #1891

Closed cstockton closed 3 years ago

cstockton commented 6 years ago

What version of dep are you using (dep version)?

v0.4.1-175-g902d09c

What dep command did you run?

dep init cd cmd/ && go run acme.go

What did you expect to see?

The acme system starts.

What did you see instead?

Many compile errors due to API changes.

Details:

I moved all my dependencies with the proper versions checked out into my vendor folder before I typed "dep init" because I need a specific set of versions that avoid bugs while maintain API compatibility. I was surprised to find it deleted my folder during "dep init", since the docs say:

dep wholly controls vendor, and will blow away any manual changes or additions made to it that deviate from the version of an upstream source dep selects.

I figured "dep init" would initialize the Gopkg files based on what my project is currently using and this was a warning that any manual changes I make once dep init is setup could be overwritten which sounded reasonable. But instead it selected it's own set of versions that don't even allow the project to come close to compiling due to API changes. It looks like it tried to just fetch the most recent version of every package, which makes "dep init" seem a lot like:

rm -rf vendor go get -u

I could see displaying an error if dep detects a problem with the versions I picked or suggesting some updates for me to consider, but I don't understand the rational behind ignoring everything my project uses to build successfully today. Maybe there is some technical documentation for this design decision I can review to better understand? Or maybe my expectations are unusual or unique? All I really want to do is have dep generate the Gopkg files from my projects current known production configuration, is that an uncommon use case?

cstockton commented 6 years ago

I just noticed after seeing a folder named _vendor-2018.. in the root of my repo so I was mistaken about the folder being deleted, my apologies. This leaves only my primary question asking if discarding the current working build for a project workout well in practice or am I an exception?

cstockton commented 6 years ago

Someone in slack pointed out I should try -gopath, I did and was very happy to see the constraint in my gopkg.toml. However dep did not incorportate the version into my project and I could not compile:

Warning: Unable to preserve imported lock v3.2.18 (eddf599) for github.com/coreos/etcd. Locking in v3.3.7 (56536de)

I tried changing "constraint" to have an "=" sign for both "override" & constraint with no success- dep is determined to always use v3.3.7. It seems it is impossible to just tell dep the exact versions I want to use? I read a lot of documentation yesterday and tried a lot of different things between dep and vgo but I could have missed something. Otherwise feel free to close this issue, thanks.

mvdan commented 3 years ago

Dep was officially deprecated earlier this year, and the proposal to archive this repository was accepted. As such, I'm closing outstanding issues before archiving the repository. For any further comments, please use the proposal thread on the Go issue tracker. Thanks!