dep init -gopath does not constrain dependency to checked out version

Created on 2 Nov 2017  路  1Comment  路  Source: golang/dep

What version of dep are you using (dep version)?

v0.3.2-48-gc47c866e

What 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.

What did you expect to see?

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.

What did you see instead?

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"
bug init

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/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.

>All comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rogpeppe picture rogpeppe  路  4Comments

rustyx picture rustyx  路  3Comments

mildred picture mildred  路  3Comments

mohanraj-r picture mohanraj-r  路  3Comments

abeMedia picture abeMedia  路  3Comments