-
Notifications
You must be signed in to change notification settings - Fork 1k
"dep ensure -update foo/bar/baz && dep prune" takes ages to complete #1170
Comments
@dcelasun hi, thanks for creating an issue for this. Sadly, this is the expected behavior right now. We write the whole vendor every time, and that brings back the pruned files. There's work going on to perform prune automatically #1020 . Due to vendor rewrite every time, dep needs all the dependencies in its cache. And if they don't already exist in cache, dep would clone all of them, and I think that's the reason for it taking so long to update in this case. Vendor rewrite is done to ensure that vendor/ has all the dependencies in their expected state. There's work going on to implement vendor verification ( #121 ), which would eventually help us avoid full vendor rewrites. Hope this helps. |
@darkowlzz Thanks, I'll just have to wait for vendor verification and hope for the best then :) |
good morning! so, wrt slowness, we have an FAQ entry with plenty of specific information - and, fortunately, cases like these will eventually be able to be completed in a matter of seconds, if not <1s, because this is mostly struggling with the segments of dep that are extremely cacheable. but i'll explain things further in the context of this particular case, because i understand how this could seem like an easier problem than it is.
so, the problem here is these expectations :) you might happen to know that these things are true beforehand for the particular dependency you're upgrading, but dep doesn't know it. dep has to prove it. isolation of any change within a depgraph can never be assumed safe\ a priori, because any update could add any new import, which could have its own new imports, which could end up overlapping with existing imports... so, yes, we absolutely must recheck the entire graph in order to be safe - and dep's first goal is safety/reliability/predictability. this is why the command is you'll note, however, in the
so again, this is a mental model thing - in dep's world, because we can't yet verify anything in |
ah, i had this queued up and didn't see @darkowlzz' response :) oh well, double-covered! |
Full description below.
What version of
dep
are you using (dep version
)?v0.3.0-142-g6ca8a48
What
dep
command did you run?dep ensure -update foo/bar/baz && dep prune
What did you expect to see?
I expected a single isolated (i.e, not depending on or imported by anything else) dependency to be updated in a few seconds.
What did you see instead?
The whole thing took ~10 minutes to complete.
I wanted to update a single dependency with
dep ensure -update
. Sincedep -update
(unintuitively, imho) restores every single already-pruned stuff during-update
I also had to rundep prune
again.Still, updating a single isolated dependency should not:
Not sure if it's helpful, but
Gopkg.lock
is below.Is there anything I should be doing differently? Is it a bug or expected behaviour?
The text was updated successfully, but these errors were encountered: