Dep: FAQ: What should you do if a dependency doesn't tag its releases?

[carolynvs]

We should add a FAQ for what to do if one of your dependencies doesn't tag its releases. Tell them to not pin the revision (see original question), and to use the manifest to track the master branch, just like go get does. Explain that the lock will handle keeping you on the same revision until you decide to update using dep ensure.

[embano1]

Oh cool, thx for opening this issue on behalf :)
Let me clarify where I´m coming from (might be a seldom case, but worth exploring imho).

• Say you started coding with the HEAD from master of pkg (pkg misses semver)
• It´s a project that takes you a while (bc you´re too busy doing other things)
• Meanwhile, the project maintainer added some commits to master, some of them breaking things in your code
• This is why you want to stay with a specific version (revision) of the pkg
• It´s a small project only for you (this is how it always starts...), so you did not care too much about vendoring in the first place (just work with the local copy)
• Then you discovered that "dep" is stable enough to be used (you´re like "AWESOME! Let´s give it a try...")
• The only way to tell dep to use your local pkg state is to use the revision as a constraint (since this pkg does not follow semver)

Instead of pinning this in the Gopkg.toml, I tried to pin the version with: github.com/author/pkg@<COMMIT_ID> (as commented by you)

This throws no error, but also does nothing (pkg stays at dep init state, i.e. "master").
Might be a corner case, granted.

[carolynvs]

Let's step back and make sure we are on the same page. 😀

If you haven't used dep yet, and your GOPATH has the right revisions of your dependencies, you should run dep init -gopath and dep will use the same branch/version/revision of what's in your GOPATH. So for example, if you depend on github.com/foo/bar and what was in your GOPATH was the master branch, on revision ff09b13, then dep would put a branch = "master" constraint in the Gopkg.toml, and a revision = "ff09b13" in the Gopkg.lock.

If you don't have a "good" GOPATH, but you know what revision you want, then run dep init and dep will generate a Gopkg.toml and lock for you with sane defaults. You know you want github.com/foo/bar to generally follow master, and start off using and older revision ff09b13.
You would run dep ensure -v github.com/foo/bar@ff09b13 which would update your Gopkg.lock, setting revision = "ff09b13".

In either scenario, your manifest has a constraint set to the master branch, but doesn't mean that you are on the latest version on master. After checking in the dep config files (and possibly vendor too), if anyone else used your project, they would get the right revision ff09b13.

The next time you randep ensure -update, dep would look for newer commits on master, and update the revision in Gopkg.lock to the tip of master.

I tried to pin the version with: github.com/author/pkg@ This throws no error, but also does nothing (pkg stays at dep init state, i.e. "master")

When you ran dep ensure -v pkg@revision, it should have updated your lock and vendor so that you were using that revision. But if you were only looking at the Gopkg.toml, it may have look like nothing. Can you double-check and let me know if it worked as described above? Or if I've totally missed the mark?

[embano1]

thx @carolynvs your summary nails it! and we´re totally on the same page!
so let me provide some feedback:

1. i wasn´t aware of the -gopath option - this fixed it for me (using a correct GOPATH)
2. however, i also tried your second suggestion, pinning pkg foo to a certain rev (just wanted to give it a try)...and it didn´t quiet work as expected:

~# dep init -v
Root project is "test"
 1 transitively valid internal packages
 1 external packages imported from 1 projects
(0)   ✓ select (root)
(1) ? attempt github.com/dustin/go-follow with 1 pkgs; 1 versions to try
(1)     try github.com/dustin/go-follow@master
(1) ✓ select github.com/dustin/go-follow@master w/1 pkgs
  ✓ found solution with 1 packages from 1 projects

Solver wall times by segment:
     b-source-exists: 1.049298108s
              b-gmal: 154.112299ms
         b-list-pkgs: 153.233823ms
            new-atom:     91.809µs
         select-root:     74.206µs
  b-deduce-proj-root:     53.582µs
         select-atom:     28.688µs
             satisfy:     27.263µs
     b-list-versions:     12.788µs
               other:      9.322µs

  TOTAL: 1.356941888s

  Using master as constraint for direct dep github.com/dustin/go-follow
  Locking in master (cca345e) for direct dep github.com/dustin/go-follow

~# dep status
PROJECT                      CONSTRAINT     VERSION        REVISION  LATEST   PKGS USED
github.com/dustin/go-follow  branch master  branch master  cca345e   cca345e  1



md5-48ef2627a9707b3c3a0116b8e755f3d4



~# dep ensure -v github.com/dustin/go-follow@e5a223af79225f6b95eccdf31c61190d22e26702
Root project is "test"
 1 transitively valid internal packages
 1 external packages imported from 1 projects
(0)   ✓ select (root)
(1) ? attempt github.com/dustin/go-follow with 1 pkgs; 2 versions to try
(1)     try github.com/dustin/go-follow@e5a223af79225f6b95eccdf31c61190d22e26702
(1) ✓ select github.com/dustin/go-follow@e5a223af79225f6b95eccdf31c61190d22e26702 w/1 pkgs
  ✓ found solution with 1 packages from 1 projects

Solver wall times by segment:
  b-list-versions: 661.279159ms
  b-source-exists: 525.414583ms
           b-gmal: 163.725084ms
      b-list-pkgs: 161.296834ms
      select-root:      87.91µs
         new-atom:     63.983µs
          satisfy:     35.768µs
      select-atom:     29.572µs
            other:      6.343µs

  TOTAL: 1.511939236s



md5-0abed2befb886828d25c6511065219b0



[[constraint]]
  branch = "master"
  name = "github.com/dustin/go-follow"



md5-29d02cbd645e3a6907194741965fef88



[[projects]]
  name = "github.com/dustin/go-follow"
  packages = ["."]
  revision = "e5a223af79225f6b95eccdf31c61190d22e26702"



md5-9d43e8739321eb5314750a3900e35578



~# dep status
Lock inputs-digest mismatch. This happens when Gopkg.toml is modified.
Run `dep ensure` to regenerate the inputs-digest.

...although I have not changed anything (besides pinning the pkg to a specific REV). Checking vendor indeed picked my specified Commit ID (so it works under the covers). But: If I run dep ensure again, it will overwrite my lock, reverting back to the latest .

Not sure if I´m making something up here. It´s working as you suggested with dep init -gopath. Just the alternative, as suggested by you, does not seem to work. What am I doing wrong?

[carolynvs]

Huzzah! I'm glad that -gopath got the job done. 🎉

As for the mismatch, that certainly isn't what I expected... boo. :grin: I was able to reproduce it easily enough though, so I can boldly state that you didn't do anything wrong. I've opened #866 to look into that more.

[embano1]

Thx @carolynvs
You´re doing a fantastic community job here. Will follow the issue, however I´m also good with your -gopath suggestion for now :)

[stevvooe]

@carolynvs Have you considered changing to a better default? The current behavior is causing users to go to upstreams and complain about not tagging a "release", which seems like an unnecessary process for packages.

If you consider the history of the Go community, using an arbitrary tag as the default will hurt adoption of dep, since it greatly differs from the behavior of go get. The current behavior doesn't actually increase the likelihood of users finding a working set of packages versions. Instead, it forces them to add an extra piece of configuration to the Gopkg.toml file.

Apologies if this is the wrong place to discuss this.

[carolynvs]

It's still our intention to encourage the community to use semver tags, and at this point isn't really up for debate as semver is a core part of how dep works. If some projects choose not to tag, it's not a dealbreaker, dep can track the master branch just like go get.

Closing because the original issue has been addressed and is in the FAQ.