the newest dep version cant't get golang package

[godcong]

the newest dep version cant't get golang package
What is the difference between the two versions?

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

dep 0.3.0
dep 0.3.1/0.3.2

What dep command did you run?

dep ensure

Gopkg.toml
[[constraint]]
name = "golang.org/x/text"
branch = "master"
source = "github.com/golang/text"

What did you expect to see?

i want get the text package from github.com
when i used dep 0.3.0 that's ok.

What did you see instead?

when i use dep 0.3.1/0.3.2：
error:
✗ unable to deduce repository and source type for "golang.org/x/text": unable to read metadata: unable to
fetch raw metadata: failed HTTP request to URL "http://golang.org/x/text?go-get=1": Get http://golang.org/x
/text?go-get=1: dial tcp 216.239.37.1:80: connectex: A connection attempt failed because the connected party
did not properly respond after a period of time, or established connection failed because connected host ha
s failed to respond.

[darkowlzz]

@godcong hi, this looks like a network error. Seems to work as expected for me. Can you try again?

[ibrasho]

Are you behind the GFW? I remember people having issues with golang.org behind the GFW.

[wittwitt]

Yes ! GFW problem !

Are you behind the GFW? I remember people having issues with golang.org behind the GFW.

to do :
export http_porxy = your GFW proxy

`
[[constraint]]

name = "golang.org/x/text"

branch = "master"

source = "github.com/golang/text"

`

But there is another problem. @ibrasho @darkowlzz
why not directly download from [github.com/golang/text]
send ( http://golang.org/x/text?go-get=1 ) to get meta data ,should on the back!

[localvar]

I'm behind the GFW and met same problem.

However, in my understanding, source is a solution for this: when dep cannot access golang.org, use github instead.

[localvar]

this issue is really annoying to me, could it be made higher priority?

[sdboyer]

to do :
export http_porxy = your GFW proxy

assuming that it's spelled correctly (http_proxy, or HTTP_PROXY), these should be picked up and used automatically by dep, including by the bit where we look for go-get metadata. that should work on tip, as well as pretty much every released version of dep.

[mspiegel]

Confirmed. On 0.3.0 I can use source as a solution when I'm having issues with my corporate proxy. On 0.3.2 this no longer works.

[ixre]

use ignored label:

 # required = ["github.com/user/thing/cmd/thing"]
 ignored = [
    "git.apache.org/thrift.git/lib/go/thrift",
    "golang.org/x/sys/unix",
 ]

[meilihao]

Me too, source does't work in a926781.

i use:

[[constraint]]
  branch = "master"
  name = "golang.org/x/crypto"
  source = "https://github.com/golang/crypto.git"

run dep ensure -update golang.org/x/crypto, get:

  ✗ unable to deduce repository and source type for "golang.org/x/net": unable to read metadata: unable to fetch raw metadata: failed HTTP request to URL "http://golang.org/x/net?go-get=1": Get http://golang.org/x/net?go-get=1: dial tcp 216.239.37.1:80: i/o timeout

[darkowlzz]

Since you guys can reproduce it, can you git bisect and find out the exact commit where this broke? That would help in finding out what changed that's could be causing this.

[diesang]

I met the same issue with 0.3.2

[godcong]

an example toml
Gopkg.toml
[[constraint]]
name = "golang.org/x/crypto"
branch = "dev"
source = "github.com/golang/crypto"

when use

dep ensure

it will first deduce the golang.org/x/crypto

i logged out on version 0.3.2
golangorgtest>dep ensure:

its run case like this:

/src/github.com/golang/dep/cmd/dep/main.go
->if err := dep.ValidateProjectRoots(ctx, p.Manifest, sm); err != nil

/src/github.com/golang/dep/manifest.go:
->for pr := range m.Constraints {
wg.Add(1)
go validate(pr)
}
->origPR, err := sm.DeduceProjectRoot(string(pr))

/src/github.com/golang/dep/internal/gps/source_manager.go
->pd, err := sm.deduceCoord.deduceRootPath(context.TODO(), ip)

/src/github.com/golang/dep/internal/gps/deduce.go
->return hmd.deduce(ctx, path)

after that deduce will be error:

Signal received: waiting for 1 ops to complete...
D:/Godcong/Workspace/g7n3/src/github.com/golang/dep/manifest.go:174: orig
The following issues were found in Gopkg.toml:

✗ unable to deduce repository and source type for "golang.org/x/crypto": unable to read metadata: unable to fetch raw metadata: failed HTTP request to URL "http://golang.org/x/crypto?go-get=1": Get http://golang.org/x/crypto?go-
get=1: context canceled

but behind the GFW, it has some problems.
i think so

[godcong]

i removed two function calls:
ValidateParams
ValidateProjectRoots
to build the dep file

after that ,when use:

dep ensure

the mirror was download correct...

[n3integration]

FWIW - I am also experiencing the same results where the 0.3.0 release is working as expected with the source override. Whereas, the 0.3.1+ releases fail with:

unable to deduce repository and source type for "golang.org/x/sys": unable to read metadata: go-import metadata not found

As an aside, is there any disadvantage to making this the default behavior (i.e. pointing all golang.org repos to github.com/golang in Gopkg.toml), at least in the case of golang.org/*? It seems to be tripping up a fair amount of users.

@darkowlzz

7a32e011e28c77ff0abed52513b536a39352dd01 is the first bad commit
commit 7a32e011e28c77ff0abed52513b536a39352dd01
Author: Sunny <me@darkowlzz.space>
Date:   Sun Sep 3 20:49:25 2017 +0530

    fix(manifest): validate project roots in manifest

    Validating ProjectRoot(s) require source manager, which is created after
    loading the project. Hence, ProjectRoot validation can't be done in
    existing validateManifest.

    This change adds `ValidateProjectRoots()` which validates only the Constraint
    and Override names to be valid ProjectRoot. Warnings are issued at stderr when
    invalid ProjectRoot is found in manifest.

    `ensure` and `status` call `ValidateProjectRoots()` expecitly.

:040000 040000 b145004b62e6928ee39441b608d1635f7050f77a 3b4852ec46de875a65a759dac9b22b5f73c51354 M	cmd
:100644 100644 11472a64a51d3dbc2b27020bbfa9d0819f2f090f 74a64da273d4cb83b62d7f55cdc103c67f7c931e M	manifest.go
:100644 100644 c79f5e02b1bef6f905c81c82ff422a44e9532c90 f206db8b822752088005fb7d063650ddaa4b9d27 M	manifest_test.go