Dep init seems to hang indefinitely

[0xdevalias]

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

⇒  dep version
dep: version: no such command

⇒  brew info dep
dep: stable 0.3.0 (bottled), HEAD

What dep command did you run?

dep init

What did you expect to see?

A new project be initialised

What did you see instead?

Nothing until I pressed control-c, then:

^CSignal received: waiting for 1 ops to complete...
panic: canary - shouldn't be possible this SourceMgr has been released, its methods can no longer be called

goroutine 1 [running]:
github.com/golang/dep/internal/gps.(*solver).unselectLast(0xc4201c0000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/private/tmp/dep-20170804-6202-1xy28iy/dep-0.3.0/src/github.com/golang/dep/internal/gps/solver.go:1237 +0x857
github.com/golang/dep/internal/gps.(*solver).backtrack(0xc4201c0000, 0xc42046b380)
	/private/tmp/dep-20170804-6202-1xy28iy/dep-0.3.0/src/github.com/golang/dep/internal/gps/solver.go:987 +0x166
github.com/golang/dep/internal/gps.(*solver).solve(0xc4201c0000, 0x0, 0x0, 0xc4201924e0)
	/private/tmp/dep-20170804-6202-1xy28iy/dep-0.3.0/src/github.com/golang/dep/internal/gps/solver.go:454 +0x787
github.com/golang/dep/internal/gps.(*solver).Solve(0xc4201c0000, 0x4b, 0x16d4440, 0xc420192420, 0xc4200140c4)
	/private/tmp/dep-20170804-6202-1xy28iy/dep-0.3.0/src/github.com/golang/dep/internal/gps/solver.go:399 +0xb1
main.(*initCommand).Run(0xc420153aca, 0xc420015860, 0xc42000c340, 0x0, 0x0, 0x0, 0x0)
	/private/tmp/dep-20170804-6202-1xy28iy/dep-0.3.0/src/github.com/golang/dep/cmd/dep/init.go:172 +0x710
main.(*Config).Run(0xc420062fc0, 0xc420062fc0)
	/private/tmp/dep-20170804-6202-1xy28iy/dep-0.3.0/src/github.com/golang/dep/cmd/dep/main.go:158 +0x855
main.main()
	/private/tmp/dep-20170804-6202-1xy28iy/dep-0.3.0/src/github.com/golang/dep/cmd/dep/main.go:45 +0x253

[0xdevalias]

So it seems doing this in a completely empty directory worked fine, just not the directory with my main.go:

import (
	"encoding/json"
	"fmt"
	"net/http"

	"github.com/Sirupsen/logrus"
	sparta "github.com/mweagle/Sparta"
)

Commenting out the above imports makes the command work correctly again.

Running with dep init -v I can see more output.. so I'm not currently sure if this is an actual issues, or just a lack of UI feedback so I think it's not working properly. If the latter, improving what is displayed to the user when not in 'verbose' mode may be beneficial.

It seems to get this far, then just hangs indefinitely.

⇒  dep init -v
Root project is "gitlab.com/devalias/gopherblazer/poc-sparta"
 1 transitively valid internal packages
 2 external packages imported from 2 projects
(0)   ✓ select (root)
(1)	? attempt github.com/mweagle/Sparta with 1 pkgs; 40 versions to try
(1)	    try github.com/mweagle/[email protected]
(1)	✓ select github.com/mweagle/[email protected] w/7 pkgs
(2)	? attempt github.com/mweagle/cloudformationresources with 1 pkgs; 1 versions to try
(2)	    try github.com/mweagle/cloudformationresources@master
(2)	✓ select github.com/mweagle/cloudformationresources@master w/1 pkgs
(3)	? attempt github.com/spf13/cobra with 1 pkgs; 2 versions to try
(3)	    try github.com/spf13/cobra@master
(3)	✓ select github.com/spf13/cobra@master w/1 pkgs
(4)	? attempt github.com/inconshreveable/mousetrap with 1 pkgs; 2 versions to try
(4)	    try github.com/inconshreveable/[email protected]
(4)	✓ select github.com/inconshreveable/[email protected] w/1 pkgs

At this point, pressing ctrl-c will produce a similar error as described previously.

[0xdevalias]

Ok.. so I tried re-rerunning this again, and eventually it actually seemed to sort itself out.. So.. partially a better UI to say it's working would be nice. And maybe there is some form of speedup/tweaking that could be done somewhere.

..snip..

Solver wall times by segment:
     b-source-exists: 3m44.640036701s
     b-list-versions:   23.142749832s
         b-list-pkgs:   10.961272199s
              b-gmal:    5.694001423s
  b-deduce-proj-root:    941.096442ms
             satisfy:     97.062615ms
         select-atom:     76.623799ms
            new-atom:      1.535083ms
         select-root:      1.318541ms
               other:       120.711µs
            add-atom:        22.427µs

  TOTAL: 4m25.555839773s

  Locking in v6 (4918b99) for transitive dep github.com/asaskevich/govalidator
  Locking in master (81e9090) for transitive dep golang.org/x/crypto
  Locking in master (a07a691) for transitive dep golang.org/x/sys
  Locking in v0.11.1 (b860c92) for transitive dep github.com/go-playground/locales
  Using ^1.0.3 as constraint for direct dep github.com/Sirupsen/logrus
  Locking in v1.0.3 (f006c2a) for direct dep github.com/Sirupsen/logrus
  Locking in master (a2efb8e) for transitive dep github.com/mweagle/cloudformationresources
  Locking in v1.0.0 (e57e3ee) for transitive dep github.com/spf13/pflag
  Locking in v9.6.0 (d529ee1) for transitive dep gopkg.in/go-playground/validator.v9
  Locking in v1.10.36 (b79a722) for transitive dep github.com/aws/aws-sdk-go
  Locking in v0.16.0 (b32fa30) for transitive dep github.com/go-playground/universal-translator
  Locking in v1.28.2 (20b96f6) for transitive dep github.com/go-ini/ini
  Locking in master (dee6347) for transitive dep github.com/mweagle/go-cloudformation
  Locking in master (2df9a53) for transitive dep github.com/spf13/cobra
  Locking in v1.0 (76626ae) for transitive dep github.com/inconshreveable/mousetrap
  Using ^0.13.2 as constraint for direct dep github.com/mweagle/Sparta
  Locking in 0.13.2 (8fca3c4) for direct dep github.com/mweagle/Sparta
  Locking in 0.2.2 (3433f3e) for transitive dep github.com/jmespath/go-jmespath

[sdboyer]

ack, 11 days! sorry, we usually respond within a couple days at the most. and, sorry that you're running into this - it's a source of continuing frustration for us that we don't have a better story here.

unfortunately, there's not a lot to say here that's not already been said in the various other issues that touch on this. basically, dep was doing a bunch of up-front cloning, which tends to be costly and take a while. the reason we struggle with providing feedback on this is because the subsystem that actually does the cloning doesn't have a good way of communicating back that it's actually doing work - it has no logging context in which to operate.

the best short-term solution we have is #1144, which should help a lot at least for this case, as you didn't actually encounter any problems other than the long clone times. i'm gonna close this in favor of that.

[0xdevalias]

Thanks @sdboyer , shall have a read of that one :)