Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Use transitive dependency's version as top-level version #1236
What version of
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!