glide
glide copied to clipboard
Masterminds
why fetching updates on a get?
I am doing glide get <foo> which takes forever - not because it's downloading <foo> but because it tries to fetch updates to all other dependencies. Why?
A couple things....
Glide resolves the complete version hierarchy. When a new package is retrieved it reworks the right version to use for everything. That way if a new package you retrieved relies on a specific version or version range the entire tree is resolved to try and make that work.
To make sure it has all the possible versions to resolves it gets an update. This causes changes if you're following the tip of a branch (such as the tip of the default branch) but doesn't if you're using versions.
Somewhere in the backlog is a request to resolve the tree on Get without updating the info we have.
just ran into this myself, seems extremely odd behaviour by default. kind of defeats the purpose of the lock to the version you originally fetched.
@james-lawrence if you fetch a new dependency how do you know the locked versions are still the right ones? For example, say you have dependency A with a dependency on B at a version of >= 1, < 2. You project resolved dependency B to version 1.4.6 and locks it. Then, you glide get dependency C and it has a dependency on B but to a version >= 1, < 1.3. The locked version of B is no invalid. You need to re-resolve the complete tree.
This example doesn't deal with the reason for an update but rather why the need to re-resolve. An optimization would be to look at the imported dependency, it's tree, and see if anything else needs to be updated. That's an optimization we've not gotten around to.
What if dependency C needed ^1.5 of B? That would also not resolve in the above example. And there are numerous cases where you would need to fetch updates to get newer versions.
Does that help explain why? There certainly are optimizations that could speed things up and pull requests are welcome.
@mattfarina the reason why a re-resolve might(!) be needed is clear. It's just very very unfortunate to make it all automatically on a get.
@tcurdt can you make a case for not re-resolving on get? Glide needs to resolve packages and versions for things like dependencies of dependencies of dependencies.
This is certainly an area we might be able to do better in post-1.0. We might be able to trail the dependencies during resolution and figure out which ones might need an update.
@mattfarina I understand why it does it, I disagree that it does it well enough to be worth doing automatically. since most of the time it seems to do the wrong thing.
edit: especially with no option to disable it.
fwiw, when we get to integrating the solver engine, i've taken special care to ensure that we hit the network only when the solver actually needs it in order to proceed - and even then, as little as possible.
I also think that glide get should at least should add an option to disable automatic updates. The procedure I'm currently doing is that after glide get I revert all the changes to the lock file besides the newly added packaged and also revert the updated dependencies in the vendor folder.
@yoshaul yeah, there's really not any disagreement THAT it's a good idea to allow granular control over updating. The problem is that it's difficult to do in glide's current design - but it's a solved problem in gps (#384). So, we're pushing to try to get gps in, ideally in 0.13.
Recently I tried to add 2 more packages to my vendor folder. If I will just copy paste them into the vendor's folder, everything looks ok. But if I try to do this with glide get pgk, glide is destroying everything, since its trying to fetch the changes, with the result that all the other packages are failing to compile.
So my question is: How I can tell glide to just clone the package I want, into the vendor's directory, and update the .yaml and .lock file?
I also think that glide get should at least should add an option to disable automatic updates. The procedure I'm currently doing is that after glide get I revert all the changes to the lock file besides the newly added packaged and also revert the updated dependencies in the vendor folder.
Looks like there's now a --no-recursive flag you can use for glide get.
