Glide update does not update packages to the latest version unless git cache is cleared

[a13xb]

Your usage example states:

$ glide up                                # Update to newest versions of the package

However, it doesn't seem to do that at all. If I start with a clean repository with glide.yaml, where none of the packages are constrained, and a matching glide.lock, none of the dependencies are updated, even though upstream has new commits. Repository remains clean.

When (pre-0.12) Glide was still not stripping VCS files, I used to be able to go into venvor tree, checkout a specific version of a single dependency and run glide update, it would update the lock file to pin the dependency at the version I checked out. So I've been left with the impression that all glide update does is transfer the state of your vendor tree into glide.lock, that's it.

Obviously now vendor tree doesn't retain VCS information, I'm not sure what exactly glide update is supposed to do, and how to actually properly update dependencies to the latest version of the upstream.

[mattfarina]

I'm a little confused about something and I think I need some more information to understand what's going on.

The glide.yaml file holds the intent while the glide.lock file holds the specific revisions being pinned to. So, a version for a dependency in the glide.yaml file that's empty, tracks a branch, or has a version range causes Glide to go to the dependency source, pull down any updates, and store them locally. It does that automatically.

There was never the intent for someone to manually checkout a version inside the repo within the vendor/ folder. Glide tells the VCS (such as Git) to go out to the source and fetch updates.

This happens via the github.com/Masterminds/vcs package. For example, with Git it will drop down to git and use commands like git fetch and git pull expecting them to go out.

Is that not happening for you?

[a13xb]

Is that not happening for you?

When I run glide update, yes, it pulls the latest from the upstream VCS into cache, but the versions in the vendor/ workspace are not updated.

Let me clarify again: my glide.yaml is a plain list of dependencies, none of them specify a branch, a tag, a commit, or range of versions, none whatsoever. My expectation was that this will result in glide update always updating the glide.lock to the HEAD of master.

This doesn't seem to be happening. After the update of local cache, my glide.lock does not change, even though there are new commits in some upstream repos.

[INFO]  Replacing existing vendor dependencies
[INFO]  Versions did not change. Skipping glide.lock update.

There was never the intent for someone to manually checkout a version inside the repo within the vendor/ folder. Glide tells the VCS (such as Git) to go out to the source and fetch updates.

Yes, that was my misguided attempt to get a pinned version of a package updated in glide.lock because glide update would not do it otherwise.

[mattfarina]

@a13xb it sounds like there is a problem and one I'm not experiencing.

Can you provide an example project or glide.yaml file? And, can you share your OS/version and Go environment (go env)?

[a13xb]

OSX: 10.11.6
Glide: 0.12.0 (via Homebrew)
Go: 1.7
Go environment:

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/alex/workspace/go"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.7/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.7/libexec/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/73/jds74fnd03q8qkfyx_8zx8400000gn/T/go-build423096790=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

Sample project:

glide.yaml

package: github.com/a13xb/glidetest
import:
- package: github.com/gorilla/mux

glide.lock

hash: be6ffa009beb31b542f3a93c368fa8213aaf2fed7fc7e10914021349fe65ce9f
updated: 2016-08-31T23:38:13.074624366+10:00
imports:
- name: github.com/gorilla/mux
  version: 9fa818a44c2bf1396a17f9d5a3c0f6dd39d2ff8e
testImports: []

Commit 9fa818a in the lock file is from June, actual HEAD of master is 0b13a92.

Running glide update:

[INFO]  Downloading dependencies. Please wait...
[INFO]  --> Fetching updates for github.com/gorilla/mux.
[INFO]  Resolving imports
[INFO]  Downloading dependencies. Please wait...
[INFO]  Setting references for remaining imports
[INFO]  Exporting resolved dependencies...
[INFO]  --> Exporting github.com/gorilla/mux
[INFO]  Replacing existing vendor dependencies
[INFO]  Versions did not change. Skipping glide.lock update.
[INFO]  Project relies on 1 dependencies.

[mattfarina]

Quick question, do you have github.com/gorilla/mux imported in your code? Glide code scans and follows imports found in the code to find the packages to use. If you have this in your glide.yaml file but didn't use it in your code it's dependencies won't be followed.

I setup an example with a file:

package main

import (
    "fmt"

    _ "github.com/gorilla/mux"
)

func main() {
    fmt.Println("test")
}

It fetched the dependencies.

Does this fix your problem?

[a13xb]

I've added this sample Go file and it adds the transitive dependency, so it completes the example, but the problem is still there.

I think it has something to do with cache.
How to replicate:

1. Starting with the empty cache, do a glide update, the dependencies are properly updated, git repos in cache end up checked out at master.
2. Discard changes to glide.lock file.
3. Do a glide install, old versions from lock file get installed, cache repos are checked out at the versions in the lock file (detached HEAD).
4. Do a glide update, update won't happen and the cache stays pointing at the commit in the lock file.
5. Remove the cache, glide update will update correctly.

[karamani]

+1
I had the same problem.

[oschwald]

I had a similar issue. Removing the cache fixed it for me.

[vuleetu]

Same here. Seems like Glide does not switch to the latest version before export to vendor.

[KatelynHaworth]

👍 This also seems to affect me.

Go Version: go version go1.6.2 linux/amd64
Glide Version: glide version v0.12.3
Go Environment:

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/liam/.golib"
GORACE=""
GOROOT="/usr/lib/go-1.6"
GOTOOLDIR="/usr/lib/go-1.6/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

[jmazzitelli]

I confirm this is happening to me too. I was wondering if I was doing something wrong, until I read this issue :) I even removed the entry of my dep from the glide.lock file (my dep is on github), ran update again, saw that the .lock file put the dep back, but vendor/ is still the old version and the entry in the .lock file is still the old hash. I want to pull the lastest from master branch, but it isn't setting my dep to the latest hash - the lock file is showing the git hash from the first time I pulled the dep via glide. Workaround: "rm -rf ~/.glide/cache/src/my-dep-directory" then run glide update.

[adangert]

same problem I was having "rm -rf ~/.glide/cache/" worked for me, glide.lock was not updating to the latest commit hash regardless of doing a glide update

[sdboyer]

i'm pretty sure the answer is "no," but just to be sure: have any of you who are experiencing this bug done any direct manipulation of the ~/.glide/cache dir?

also, if anyone is able to create some exact steps to reproduce, it would be tremendously helpful in solving this problem.