dep init -v在执行时挂起

Question

I'll start with a disclaimer here. I'm running go on Ubuntu 18.0.4 on Windows subsystem.

I have a package in which I was able to run "dep init" successfully from the windows command line. I created a new clone (successful clone, so no network connectivity issues) of the repo in my Ubuntu subsystem and ran "dep init."

This is when I run into problems. Dep just hangs after pulling a single package down. Subsequent calls to dep init do not pull more packages. Running "dep init -v" produces the following:

#> dep init -v
Getting direct dependencies...
Checked 14 directories for packages.
Found 3 direct dependencies.

Take a look at the attached screen capture to see that process threads are spun up but are doing nothing (0% CPU and RAM usage).

Screen Capture with HTOP and my dep pkg folder structure

Things I've tried:

1. Turning it off and on again.
2. I've completely cleaned out my dep package folder and re-run dep init. This is how I know that there is just a single package that is actually getting pulled.
3. Made sure that my ssh keys are up-to-date with github.

Answer 1

dep was the "official experiment." The Go toolchain, as of 1.11, has adopted an approach that sharply diverges from dep. As a result, we are continuing development of dep, but gearing work primarily towards the development of an alternative prototype for versioning behaviour in the toolchain.

Go 1.11 included preliminary support for modules and includes support for vendoring.

You should stop using dep and refer to How to Define a Module to migrate your project.

First, navigate to your source tree, and then follow these instructions:

Create the initial module definition and write it to the go.mod file:

$ go mod init                  

This step converts from any existing dep Gopkg.lock file or from any of the other nine total supported dependency formats, adding require statements to match the existing configuration.

go mod init will often be able to use auxiliary data (such as VCS meta-data) to automatically determine the appropriate module path, but if go mod init states it can not automatically determine the module path, or if you need to otherwise override that path, you can supply the module path as an optional argument to go mod init, for example:

$ go mod init github.com/my/repo