dep are you using (dep version)?v0.3.2-48-gc47c866e
dep command did you run?dep init -gopath
Searching GOPATH for projects...
Using v1.8.2 as constraint for direct dep k8s.io/kubernetes
Locking in v1.8.2 (bdaeafa) for direct dep k8s.io/kubernetes
Following dependencies were not found in GOPATH. Dep will use the most recent versions of these projects.
golang.org/x/oauth2
k8s.io/api
k8s.io/apimachinery
k8s.io/apiserver
...
This, despite that k8s.io/api, k8s.io/apimachinery, and k8s.io/apiserver are in GOPATH.
I expected all the k8s.io/* packages to be constrained to the versions that are checked out, because dep help init says:
An alternate mode can be activated by passing -gopath. In this mode, the version
of each dependency will reflect the current state of the GOPATH. If a dependency
doesn't exist in the GOPATH, a version will be selected based on the above
network version selection algorithm.
Only k8s.io/kubernetes was constrained to the version that is checked out.
Here's a script to replicate the problem:
#!/bin/sh
set -eu
workdir=$(mktemp -d -t dep-test)
printf "\n===> creating GOPATH in $workdir/go\n"
export GOPATH=$workdir/go
mkdir -p $GOPATH/src/{github.com/digitalocean,k8s.io}
printf "\n===> cloning repositories\n"
cd $GOPATH/src/k8s.io
for repo in api apiextensions-apiserver apimachinery apiserver client-go kube-openapi kubernetes
do
git clone https://github.com/kubernetes/$repo &> /dev/null &
done
cd $GOPATH/src/github.com/digitalocean
git clone https://github.com/digitalocean/digitalocean-cloud-controller-manager &> /dev/null &
printf "\n===> waiting for cloning to finish\n"
wait
printf "\n===> checkout tags\n"
for repo in api apiextensions-apiserver apimachinery apiserver client-go
do
cd $GOPATH/src/k8s.io/$repo
git checkout kubernetes-1.8.2
done
cd $GOPATH/src/k8s.io/kubernetes
git checkout v1.8.2
printf "\n===> checkout known k8s 1.8.2 client\n"
cd $GOPATH/src/github.com/digitalocean/digitalocean-cloud-controller-manager
git checkout f9a9856e99c9d382db3777d678f29d85dea25e91
printf "\n===> removing all vendored code\n"
rm -rf vendor
printf "\n===> vendoring from GOPATH\n"
dep init -gopath
printf "\n===> produced Gopkg.toml:\n"
cat Gopkg.toml
printf "\n===> packages are in $GOPATH/src\n"
ugh, i'm sorry, i don't know how we missed this. thanks for the detailed issue, and especially the script to reproduce!
so, this is interesting - it does seem to point to some bugs, or at the very least some misleading error messages. it complains of k8s.io/apimachinery, k8s.io/api and k8s.io/apiserver not existing, but they do exist - they just don't have Go code in the root package. at least, i'm guessing that's the problem. on my first pass through, that's my best guess.
Most helpful comment
ugh, i'm sorry, i don't know how we missed this. thanks for the detailed issue, and especially the script to reproduce!
so, this is interesting - it does seem to point to some bugs, or at the very least some misleading error messages. it complains of
k8s.io/apimachinery,k8s.io/apiandk8s.io/apiservernot existing, but they do exist - they just don't have Go code in the root package. at least, i'm guessing that's the problem. on my first pass through, that's my best guess.