Find outdated dependencies and update them

[ernestoalejo]

To help when updating dependencies. Right now I have to manually check if there is a new commit, get the hash, write it and update. A command like npm outdated would be very useful.

At least reinstall the dependency from zero if asked to do it; e.g.: glide get foo.com/bar to get the latest version, like the first time I used it. Currently it warns: "Package "foo.com/bar" is already in glide.yaml. Skipping". It does not have to be get, another different command can be added too.

Also if you don't specify a version in glide.yaml; you have to remember to delete the entry in glide.lock before glide update. It's confusing.

[mattfarina]

A couple things.

1. If no version is specified the glide.yaml file the default is to follow the tip of the default branch.
2. Running glide update will resolve the dependency tree and versions based on the glide.yaml file. If it's following the tip of master on a project it will update to the latest commit. The new state will be written to the glide.lock file.

You shouldn't have to remove a dependency to update it. Glide does that for you.

[ernestoalejo]

That is precisely what I want glide to do; but it's not the current behaviour. Running glide update with the following pair of files does nothing to update to the latest commit (b2c7a7da...).

glide.yaml:

package: tt
import:
- package: github.com/juju/errors

glide.lock:

hash: c5d0b5564bb639895d120e9a72eb397a6eb6efc23a772e808c9a49e20db395de
updated: 2016-03-28T02:44:51.503697917+02:00
imports:
- name: github.com/juju/errors
  version: 797449fa4bdba2948dfc581cdc3acf625272a8d6
devImports: []

  glide update
[INFO] Downloading dependencies. Please wait...
[INFO] Fetching updates for github.com/juju/errors.
[INFO] Resolving imports
[INFO] Downloading dependencies. Please wait...
[INFO] Setting references for remaining imports
[INFO] Project relies on 1 dependencies.

# Still on 797449...

  glide install
[INFO] Downloading dependencies. Please wait...
[INFO] Fetching updates for github.com/juju/errors.
[INFO] Downloading dependencies. Please wait...
[INFO] Setting references.
[INFO] Setting version for github.com/juju/errors to 797449fa4bdba2948dfc581cdc3acf625272a8d6.

  glide -v
glide version 0.10.1

[mattfarina]

I'm rather confused. I just started with this glide.yaml:

package: tt
import:
- package: github.com/juju/errors

It was created using glide init on the codebase. I then ran glide update and it produced the following glide.lock file:

hash: c5d0b5564bb639895d120e9a72eb397a6eb6efc23a772e808c9a49e20db395de
updated: 2016-03-27T20:59:57.085268681-04:00
imports:
- name: github.com/juju/errors
  version: b2c7a7da5b2995941048f60146e67702a292e468
devImports: []

This does have the latest commit. This is using Glide 0.10.1. I wish I could reproduce your issue.

Does your git client have a cache? Glide drops down to git to make calls to GitHub.

[ernestoalejo]

I made up a new glide.yaml file to use a public repo; ignore the timestamp in the updated field. Suppose that the glide.lock file was generated in a previous glide update run 1 month ago and 797449 was the last commit at the moment. Now a new commit (b2c7a7da5) is available and I want to update to it.

If you don't have a previous glide.lock file it works well; it's like the first run and everything gets resolved from scratch. However, if you do have a previous glide.lock file, you have to delete the lib or the whole file altogether to force the update.

[mattfarina]

Are you using glide update or glide install? glide install installs what's listed in the glide.lock file. glide update re-resolves the tree and generates a new lock file.

[ernestoalejo]

Both; though I only expected glide update to work as you said. See the console output here: #356 (comment)

glide update is not updating the lock file correctly, the timestamp changes but the commit is the same as before and doesn't resolve anything.

[technosophos]

Out of curiosity, if you set version: master in your glide.yaml, does that force it to the tip of master?

[ernestoalejo]

It works with version: master

[technosophos]

Hmmm, I believe you found a bug. It should work the same with version: master as it does without version: master. Thanks for reporting this.

[technosophos]

See also #327