-
Notifications
You must be signed in to change notification settings - Fork 1k
vendor.orig causes subsequent dep ensure's to explode #1304
Comments
hmm, yeah, we have a deeper problem here, which is needing to do signal handling at a higher level (in dep, rather than gps directly), then we need to plumb context through the various fs funcs in order to achieve safe aborts. THEN link all that together with the context being plumbed more thoroughly through the solver in #1230. that's a fair bit of work. in the meantime, though, we should be able to handle this scenario more sanely with some basic guards in place. |
...actually, sorry, i misread this. i thought that you were seeing errors because it was tripping on the this is where we pick that temporary location for the current Lines 378 to 388 in df32e15
with recent changes, we're now fine if we just change that dirname slightly, to making a PR now. |
While there's more work to be done in making all of this safe in the event of a signal being sent to dep, this change at least means that if a signal is sent during the rename and a .vendor.orig directory is left behind, subsequent runs will treat its contents as ignored. Fixes golang#1304
What version of
dep
are you using (dep version
)?v0.3.1-122-g98f625e
What
dep
command did you run?dep ensure -v
^C
dep ensure -v
What did you expect to see?
Normal dep ensure stuff
What did you see instead?
and on and on and on for pages
This was caused by the
vendor.orig/
folder left around by the firstdep ensure
which was canceled.Dep should abort if it finds this folder, or at least ignore it.
The text was updated successfully, but these errors were encountered: