-
Notifications
You must be signed in to change notification settings - Fork 1k
Revision / branch in manifest is ignored #321
Comments
Do any packages in If so, then hopefully it's a bug in how we report constraints to gps, not gps itself, because otherwise I did something hairy. Could you dump the results of (/cc @kris-nova - looks like there's a counting bug in the trace output, see it hopping up and down?) |
They don't, no - its imported transitively by Prometheus. I made it an override instead, and that seemed to do the trick:
Thanks! |
Yep, that was the backup - an override will do it. I'm interested more in this case in general, though - what are the circumstances that lead to a situation where you need to use a specific version of a transitive dep? In the simple model, we generally assume that if it's not your direct dependency, you don't have to care about it. Also, overrides are really a sledgehammer. For this case, it might be preferable to create a dummy import, or a |
This is a bit of a special case, but cortex uses prometheus as a library, and prometheus has to use a specific version of the azure client library. The real problem is the azure client library latest version isn't up to date enough if you go by the tags. |
That doesn't actually sound like a special case at all - it's one of the exact cases we've designed to accommodate. If prometheus had its own manifest that declared its constraint on azure-sdk, then the solve for cortex would incorporate that constraint, and you wouldn't need to do anything. It looks like prometheus is currently managed with govendor. As discussed in #222, it would be possible for us to make dep able to read and convert that information on the fly, in such a way that you'd be able to rely on existing versions of prometheus and still pick up that constraint on azure-sdk. (There would be side effects to this, though, and if we do something like that, it's likely to be very cautious) |
Ah, very cool. @juliusv - do you think the prometheus devs would consider moving to dep at some point? |
I would encourage no one to move to dep until we at least close out #276 😄 manifest and lock will be changing structure, names, formats, and we won't provide an upgrade path. We're pushing as hard as we can on getting that done, but for now, experimentation and feedback is what we really need to get there. |
@tomwilkie I'm pretty sure we'll move to dep the second it's the officially recommended Go tool for managing dependencies :) Can't wait for this to be standardized in Go-land. |
@juliusv exactly what i love to hear! 🎉 if you have a chance to test it out and give feedback before then, that'd be awesome, too. |
I need to use a specific version of https://github.com/Azure/azure-sdk-for-go (revision bd73d950fa4440dae889bd9917bff7cef539f86e).
If I run
dep ensure -v github.com/Azure/azure-sdk-for-go@bd73d950fa4440dae889bd9917bff7cef539f86e
, dep selects the latest tagged release:The manifest is updated correctly, but the lock file shows this not being honored:
The text was updated successfully, but these errors were encountered: