Skip to content
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.

dep ensure does not update package to the revision in Gopkg.lock #865

Closed
nkovacs opened this issue Jul 20, 2017 · 7 comments
Closed

dep ensure does not update package to the revision in Gopkg.lock #865

nkovacs opened this issue Jul 20, 2017 · 7 comments

Comments

@nkovacs
Copy link

nkovacs commented Jul 20, 2017

What version of Go (go version) and dep (git describe --tags) are you using?

go1.8, dep 6c5ebb9

What dep command did you run?

I updated my package on github. Ran dep ensure -update to update it in a project. The new revision was written to Gopkg.lock. I committed the file and pushed (vendor is not commited), pulled in another directory that already had an older package in vendor, and ran dep ensure -v there.

Root project is "temp/depbug"
 1 transitively valid internal packages
 1 external packages imported from 1 projects
(0)   ✓ select (root)
(1)     ? attempt github.com/nkovacs/go.rice with 1 pkgs; at least 1 versions to try
(1)         try github.com/nkovacs/go.rice@master
(1)     ✓ select github.com/nkovacs/go.rice@master w/2 pkgs
(2)     ? attempt github.com/daaku/go.zipexe with 1 pkgs; at least 1 versions to try
(2)         try github.com/daaku/go.zipexe@master
(2)     ✓ select github.com/daaku/go.zipexe@master w/1 pkgs
(3)     ? attempt github.com/kardianos/osext with 1 pkgs; at least 1 versions to try
(3)         try github.com/kardianos/osext@master
(3)     ✓ select github.com/kardianos/osext@master w/1 pkgs
  ✓ found solution with 4 packages from 3 projects

Solver wall times by segment:
     b-source-exists: 2.956907456s
         b-list-pkgs:  168.82931ms
              b-gmal: 158.445407ms
         select-atom:     384.63µs
             satisfy:    309.666µs
            new-atom:    235.044µs
  b-deduce-proj-root:     97.242µs
         select-root:     81.529µs
               other:     17.193µs

  TOTAL: 3.285307477s

What did you expect to see?

I expected the package in vendor to be updated to the revision that is in Gopkg.lock

What did you see instead?

The package in vendor was not updated.

Gopk.toml is empty. Gopk.lock:

# This file is autogenerated, do not edit; changes may be undone by the next 'dep ensure'.

[[projects]]
  branch = "master"
  name = "github.com/daaku/go.zipexe"
  packages = ["."]
  revision = "a5fe2436ffcb3236e175e5149162b41cd28bd27d"

[[projects]]
  branch = "master"
  name = "github.com/kardianos/osext"
  packages = ["."]
  revision = "ae77be60afb1dcacde03767a8c37337fad28ac14"

[[projects]]
  branch = "master"
  name = "github.com/nkovacs/go.rice"
  packages = [".","embedded"]
  revision = "4a03840284012311ccc7cb44965fad78d9e010a9"

[solve-meta]
  analyzer-name = "dep"
  analyzer-version = 1
  inputs-digest = "6aa768e4f3294c299bc5422a8ba6b95bbe332c835af19943b66962c5e3ce1e56"
  solver-name = "gps-cdcl"
  solver-version = 1
@carolynvs
Copy link
Collaborator

Did you specify the -update flag?

@nkovacs
Copy link
Author

nkovacs commented Jul 20, 2017

After pulling in the other directory? No. I don't want to update. I want the revisions in Gopkg.lock.

@carolynvs
Copy link
Collaborator

Can you explain what you mean by "pulled in another directory that already had an older package in vendor"?

@nkovacs
Copy link
Author

nkovacs commented Jul 20, 2017

Before I ran dep ensure -update in directory A, i cloned the project into directory B and ran dep ensure. This installed the revision which was in Gopkg.lock at the time into the vendor directory of B.

Then I ran dep ensure -update in directory A, which updated the revision, committed the lock file, pushed, and pulled in directory B.

@carolynvs
Copy link
Collaborator

Ah okay. dep ensure doesn't always populate vendor, only when the imports in your code have changed, or when the manifest has changed. dep computes a hash and stores it in the lock. When vendor already exists, and the hash hasn't changed, dep doesn't write to vendor.

So for the workflow that you are using now, I recommend first deleting vendor in Directory B, then running dep ensure.

We have #121 open to track adding vendor verification.

@sdboyer
Copy link
Member

sdboyer commented Jul 21, 2017

It also sounds like dep ensure -vendor-only will help with this use pattern, once #489 is merged.

@nkovacs
Copy link
Author

nkovacs commented Jul 21, 2017

I tried that branch, and not only does dep ensure -vendor-only correctly update the vendor directory, so does dep ensure. Which makes sense, the two shouldn't differ in this regard.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants