-
Notifications
You must be signed in to change notification settings - Fork 1k
Incorporate SolveMeta into LockDiff #623
Comments
Hi. I will take a stab at this. |
Hi @carolynvs. I took a look around the code and I think I understand what is being asked. It's not as simple as adding serialization. The biggest work is around gps.Lock interface having no idea about the new SolveMeta data which is in root namespace. I will probably refactor SolveMeta or an interface resembling it into gps, and then I would have to add at least getter for it into gps.Lock. Before I start on this not so trivial refactoring, I would like little guidance from you, @sdboyer or someone else on the project if I am on the right track. |
Yeah, this'd be a little more involved, as Hmm...I think, maybe, we should actually go the opposite direction, and drop the input hash from the diff, so that we're ignoring all the solve meta. That's information people can see in a |
LockDiff now uses only project dependencies to identify changes, thus ignoring any changes to the SolveMeta iformation. If required changes in the SolveMeta can still be seen using source diffs. Modified and added tests to check new behaviour.
LockDiff now uses only project dependencies to identify changes, thus ignoring any changes to the SolveMeta iformation. If required changes in the SolveMeta can still be seen using source diffs. Modified and added tests to check new behaviour.
Currently LockDiff only compares the memo. but now that #584 has added new metadata fields, the LockDiff should be updated to include them as well. Also we should print "Inputs Digest" instead of "Memo" now that the field has been renamed.
For example:
Old Gopkg.lock
New Gopkg.lock
Running
dep ensure -n
would print:The text was updated successfully, but these errors were encountered: