Closed ascandella closed 7 years ago
Yeah I've had this backburnered for a little while - it's the same panic as #607 and #357. As far as I've surmised from previous passes, the actual, data-level problem is that the depth-first traversal logic in wmToReach()
assumes that there are no "internal" import statements pointing to packages that do not exist.
One user-visible way that can arise is if a dependency's main
is in the required
list in Gopkg.toml
. There are other ways we can get there too, though, as those conditions can't occur on dep init
. Either way, the solution probably ends up being the same.
(not that i've decided on exactly what that solution should be just yet 😛 )
OK, we should probably just close this as a duplicate then, right? Or leave this open since I added the dlv
output?
I'm fine to leave it open - the dlv output is helpful, but we also need to be cognizant of the different input circumstances that might lead to it occurring. as i'm not immediately clear on how a dep init
could reach this bug, it seems like something new here 😄
Err whoops, not #357, #351
closing this, as it's band-aid-ed now and #351 is enough of a marker issue for the underlying problem that remains
Go Version 1.8.1
Architecture Darwin x86_64 (Sierra 10.12.4)
I can consistently reproduce this on https://github.com/uber-go/zap@fab453050a7a08c35f31fc5fff6f2dbd962285ab (tip of master at the time of writing):
Running
dep init
with the latest master ofdep
(8bdd9e5cb8e331a8fb505d9c4f62bd58bbac40b3)Diving into variables with delve:
basically,
fromErr
is nil and the comment above suggests that should never be the case.It would be pretty easy to add a comma-ok and check for that, but I'm unfamiliar with this part of the codebase and don't want to band-aid if this is indicative of a larger issue. Looks like the code was originally added in 31795085c1afcd25d3c87e140f9d60b19e7684e7 but later moved.