-
Notifications
You must be signed in to change notification settings - Fork 1k
Feedback: init and status should provide some user feedback #62
Comments
Gotta subdivide these into different cases. To be clear - looking at your gist, it seems like you ran There's a fair bit of other feedback that's provided with If at least one dep project isn't found, then we have to fall back to solving. We could certainly provide some clearer output about what wasn't found locally, and has thus necessitated performing a solve. ...which will hit network, of which we could advise the user. From here, though, the network interaction question is entirely about what gps does, and so folds in with #67. For We could, perhaps, do it selectively - skipping, for example, anything in the lock with a plain/non-semver version or rev, as the idea of a "latest" there is semantically null (as you noted in your gist). Again, though, other improvements fold in with #67. |
We could still provide more without |
IMO at minimum it'd be worth outputting the projects+versions it finds, even without |
My first run of I tried |
Looks like I didn't. I was on 76df5ce, pulled earlier today. Things change so fast around here. 😉 It was much faster this time, but verbosity is still not great. My project folder has plenty of non-Go code, including folders in my UPDATE: apologies. I had used |
Fixes golang#62. Also fixes a weird loop issue that caused erroneous poisoning in wmToReach()'s depth-first traversal.
i'm gonna call this complete, just because we've totally overhauled |
This is based on my first run with the tool. I propose that
dep init
anddep status
should give some kind of immediate feedback to the user, to indicate they're going out to the network and the operation may take a little time. At the moment I don't have much confidence in what's going on.What do we think? Should this be hidden behind a
-v
flag?The text was updated successfully, but these errors were encountered: