-
Notifications
You must be signed in to change notification settings - Fork 1k
Use transitive dependency's version as top-level version #1236
Comments
hi, welcome! thanks for the detailed the issue. i think this might be a small solver bug. we sometimes have a bit of a blind spot around plain revisions in |
@sdboyer Thanks for the quick response! I added a tag on
Additional questions I have now:
And most importantly:
Also, even though I'm digging into this revision issue, I really do appreciate that |
i do love guessing right 😄
This is another judgment call we made in pursuit of that same goal - not having revisions in
The detailed answer reaches into the depths of dep's solver, and I don't know where the problem is exactly (if I did, we wouldn't have this bug!), as it's a subtle order-of-operations issue. But, the problem arises from solver mechanics: when the solver is trying to figure out which version of a dependency to use, it creates an ordered list of versions to try. That list does not, by default, contain revisions, because that would mean the solver would have to search every revision in every dependency to see if they work. Instead, when we encounter a revision constraint, we hack that version in to the list at the front. My hunch was that the problem arose when that hack is applied on an already-empty (or perhaps just a single-item) queue, as it's basically the only time that we mess with the version list after initial construction (like I said, it's a hack), so it was the only plausible way that i could imagine the solver missing a version it needed to try. And that's why adding another to
Apart from waiting for a fix, which may take me a little while to get to, I think your best bet is likely to be picking out the revision of Alternatively, ask the maintainers of
i'm glad you agree! 🎉 🎉 |
What version of
dep
are you using (dep version
)?v0.3.1
What
dep
command did you run?cd $GOPATH/src/github.com/benmai/dep-test-c && dep init
What did you expect to see?
I've set up three example repositories, benmai/dep-test-a, benmai/dep-test-b, benmai/dep-test-c to demonstrate this:
dep-test-a
has no dependencies and two revisions,bfe5ef
(the earlier revision) and790c1e4
(the later revision).dep-test-b
importsdep-test-a
and has a constraint to set its version ofdep-test-a
tobfe5ef
(the earlier revision).dep-test-c
importsdep-test-a
anddep-test-b
.dep-test-c
'sGopkg.toml
has not yet been created, since we're runningdep init
now.I expect to see:
dep init
to finish without errors.Gopkg.toml
to be empty (the dependencies should be inferred from imports).Gopkg.lock
to contain:dep-test-a
atbfe5ef
(the earlier revision).dep-test-b
at7a70e4a
(its only revision).What did you see instead?
It appears that since
dep-test-c
importsdep-test-a
,dep init
begins by forcingdep-test-a
to the tip ofmaster
instead of deferring todep-test-b
's constraint.Is this expected behavior? It seems I would have to create a
Gopkg.toml
by hand here, which I don't want to do. I would like to use the version ofdep-test-a
whichdep-test-b
specified in itsGopkg.toml
by default.The text was updated successfully, but these errors were encountered: