This repository has been archived by the owner on Sep 9, 2020. It is now read-only.
Gopkg.toml and Gopkg.lock are out of sync -- even after running dep ensure #1227
Comments
|
Is providing the |
|
hi, welcome! eek, sorry, this is a surprising outcome, and definitely not one that should be possible.
definitely helpful, yes. probably the best thing to go on at this point. could you also check to make sure that that bare
yeah...one of many things that needs an FAQ entry. god, i wish i had time to just write docs for a week. |
|
Hi Sam, I just removed all files that I suspect to belong to dep's internal state and did the following (internal package names have been sanitized): |
|
huh. these:
are...very weird. do you have a GOPATH set up inside of your project directory, which is then within yet another GOPATH? |
|
FYI, #1225 is merged now so you should be able to run I'm still interested in what is causing this bug though. |
|
@sdboyer yes, indeed. My project has rather complicated GNU Make based build script for several reasons and I have |
|
@hillu i'm sorry, but we really can't make any promises about dep working in this kind of scenario. dep's design entails that we not only statically analyze the go files in your project, but that we can make sense of them as a tree, rooted at your |
|
@sdboyer I am sorry for mistreating your tool so badly, it was all done with good intentions :-) I seem to have found a workaround: dep ignores directories that begin with an underscore or dot, so this breaks the cycle introduced by the symlink. |
|
@hillu haha, it's OK! you've gotta do what you've gotta do, and some older school Make-based projects definitely can have fs layout requirements that, at least by today's standards, may be quite circuitous. (also, dep/go are particularly hostile to symlinks).
it does...sort of. even though it "ignores" them in the sense that dep will no longer think it has to honor the imports therein, it will still scan those directories on every single run of the tool, so there is still a performance impact to doing it this way. but correct and possibly somewhat slow is still far, far better than unworkable 😄 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of
depare you using (dep version)?0.3.1, and master (82b3908), fetched using go get and built using golang 1.8-1 as shipped with Debian/stretch (amd64).
What
depcommand did you run?What did you expect to see?
I would have expected
dep ensureto get the files "back in sync" (whatever that means from the perspective with my pure user-hat on).What did you see instead?
See above, the message keeps appearing.
The text was updated successfully, but these errors were encountered: