Detected semantic version... from where?

[HelloGrayson]

I often see this in the output of glide up:

[INFO]  --> Detected semantic version. Setting version for gopkg.in/inf.v0 to v0.9.0.
[INFO]  --> Detected semantic version. Setting version for github.com/onsi/ginkgo to v1.2.0.
[INFO]  --> Detected semantic version. Setting version for github.com/pkg/errors to v0.7.1.
[INFO]  --> Detected semantic version. Setting version for github.com/uber/tchannel-go to v1.2.1.
[INFO]  --> Detected semantic version. Setting version for github.com/onsi/gomega to v1.0.

When debugging a dependency issue, I find myself asking: what was the codepath that Glide used that ultimately triggered setting version A for library B. What exact glide.yaml or library resulted in v0.9.0 being installed, or commit 02510b74613671b0c9e7b60b790baa28845b081e.

Perhaps a --verbose mode that will say something like:

Detected semantic version from <file>. Setting version for gopkg.in/inf.v0 to v0.9.0

This would be really useful when you're trying to figure out why the heck v0.9.0 is being installed instead of v0.11.0, for example.

Thoughts?

[heralight]

You can more about Semantic Versioning 2.0.0

http://semver.org/
https://en.wikipedia.org/wiki/Software_versioning
https://wiki.debian.org/UpstreamGuide#Releases_and_Versions

In your case you don't have v0.11.0 for gopkg.in/inf.v0 ... if it will be the case, v0.11.0 > v0.9.0

[HelloGrayson]

@heralight I understand semver perfectly well - that's not the ask here.

The ask is Glide's output should show WHERE it decided package A should be installed at version X. Specifically what file lead to the decision that version X should be installed as opposed to version Y.

[sdboyer]

Generally speaking, glide picks the "first" version available for a given project that's admitted by constraints. Offhand, I don't know how glide decides that - i.e., if it tries semver first, or branches...

However, gps may also be of some help here (once integrated), as it has a trace mode for the solver. Here's some recent output: https://gist.github.com/mattfarina/4465b759406a196aac1b9375e7963783 as an example of what that looks like. The UX still needs love, for sure, but the basic info is there. (And in gps, I can tell you for sure the order in which versions are tried).

Exactly how glide makes use of that trace mode, though, is still an open question - #565. There's a lot of output currently generated by glide that simply won't be possible anymore, so we've got some decisions to make on how to wedge all these pieces together.

[niyue]

I ran into similar situation as well. When I build my project, a transitive dependent library was reported with some incompatible API compilation issue, but I cannot easily where this transitive dependency actually comes from. Knowing the origin and why a dependency is needed will help for troubleshooting.