New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separately enumerate/split out some of the inputs to the lock's memo #508

sdboyer opened this Issue May 3, 2017 · 1 comment


None yet
1 participant
Copy link

sdboyer commented May 3, 2017

The memo field in the lock is an important component in the overall strategy for making dep fast and reliable. Its exact behavior is described in greater detail in the gps wiki, but the essence is this: it's a hash digest of string representations of all the locally-knowable inputs that could affect solving outputs. When dep ensure or dep status (or whatever) are run, they pull together all this locally-available info, compute a hash, and compare it to what's in Gopkg.lock. If it's a match, then we know the project's code+Gopkg.toml are in sync with Gopkg.lock. (This is literally memoization, which is why the field is named what it is).

However, as with all hash-matching schemes, it has the disadvantage that, if there's ever a mismatch, we cannot know why that mismatch occurred. And, if hash inputs can vary in ways that are non-obvious to users (like, say, the totally-not-visible-outside-the-code analyzer version that is incorporated into the memo), team members can find themselves ping-ponging hash changes back and forth with each other, and/or a CI server, with no idea what the problem is. That would rapidly turn such mismatches into a false alarm, causing people to ignore it. That would certainly undermine the overall UX of the system that we're going for, and possibly even a real aspect of system integrity.

Now, I do think the hashes have value. We could, for example, create a simple HTTP service that takes a hash and returns a solution for it, thereby obviating the need for solving. Or, more low-tech, just keep a history of solutions somewhere else on disk locally, memo-addressable, the hash provides a convenient addressing system in this respect. But we need to split out some of the information in the memo into separate, explicit fields in Gopkg.lock so that we can provide more detailed feedback users about what might be causing weird mismatches.

I don't have a specific plan on this yet, but I'll update the ticket when I do.


This comment has been minimized.

Copy link

sdboyer commented May 18, 2017

Hmm, this should probably incorporate #421.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment