dep status show nothing after dep init

[kevingo]

Hi, if I use dep init on one project, and it will create manifest.json、lock.json and vendor/ successfully. After that, I use dep status, it shows nothing, such as :

$ dep status
PROJECT  MISSING PACKAGES

After I continue typing dep ensure, the dep status shows expected information, such as :

$ dep status
PROJECT                          CONSTRAINT     VERSION        REVISION  LATEST   PKGS USED
github.com/davecgh/go-spew       *              v1.1.0         a7a0063   v1.1.0   1
github.com/go-ini/ini            *              v1.27.0        e7fea39   v1.27.0  1
github.com/gucumber/gucumber     *              branch master  71608e2   71608e2  2
github.com/jmespath/go-jmespath  *              0.2.2          3433f3e   0.2.2    1
github.com/pmezard/go-difflib    *              v1.0.0         c0b812d   v1.0.0   1
github.com/shiena/ansicolor      *              branch master  a422bbe   a422bbe  1
github.com/stretchr/testify      *              v1.1.4         69483b4   v1.1.4   2
golang.org/x/net                 branch master  branch master  4971afd   05d3205  2
golang.org/x/tools               branch master  branch master  8b84dae   d63e2b2  3

But the only changes between dep init and dep ensure is the memo field in the lock.json:

diff --git a/lock.json b/lock.json
index 47a671e..1ce2d08 100644
--- a/lock.json
+++ b/lock.json
@@ -1,5 +1,5 @@
 {
-    "memo": "32049ca53089c48b7465aa66569de85b1fae6540d8424cf70811cfb846f795e6",
+    "memo": "92574f8da2bd8e7ccb9e86f4251ca33e3110ee6d18c1b706f0e96ad45499238d",
     "projects": [
         {
             "name": "github.com/davecgh/go-spew",

Is this behavior designed by intention? Or any reason?

Thanks

[lepinkainen]

This is weird UX, I think dep status should direct the user into running dep ensure just to prevent confusion.

[sdboyer]

Ugh, yeah, this is a no-good situation. Thanks for writing it up in such detail.

Is this behavior designed by intention? Or any reason?

It's definitely not intended, and is something we need to work on in the next round of improvements to dep init. There's no reason that memo field shouldn't be correct after the first dep init run.

[kevingo]

@sdboyer .Good to hear about the improvement. :)

[darkowlzz]

Is any work going on to fix this bug? I can take it up provided some help :)

After going through the code, I think it can be fixed in different 2 ways:

• Call ensure internally at every init call.
• Initialize Memo in the initial Lock created in init.go here. Although I'm not sure how to create an initial Memo hash.

[sdboyer]

@darkowlzz 🎉 🎉 🎊 !!

Nope, no current work underway, as it's kinda tied up with refactoring the behavior of the commands more generally.

Initialize Memo in the initial Lock created in init.go here.

This is closer to the way to go, I think. At least in the ballpark.

What'd be ideal, is if you could try to carve out the minimum possible implementation that's consistent with the new spec for init.

Although I'm not sure how to create an initial Memo hash.

The memo is a hash of the arguments passed to the solver. (You can see the actual string values passed in to that with the hidden subcommand dep hash-inputs). The fact that we have this misalignment indicates that the solve run we do - if any - during init is using a different set of inputs than the ones we ultimately create.

I think all this should be laid out in the new spec doc 😄