Systematic support for "warnings"

[fabulous-gopher]

From @sdboyer on July 26, 2016 18:25

We need a system of warnings when things occur that aren't necessarily grounds to stop the solver, but aren't exactly optimal either.

Much of this system will necessarily be about how to report the information - clearly, it has to emerge from somewhere other than the TraceLogger. That means two separate reporting paths, though, which is...well, super fun.

In any case, for now, this issue is useful as a place to keep a running list of conditions under which we should issue warnings:

• A None constraint is explicitly given by a manifest
• A malformed ProjectIdentifier - root or net name - is returned from a Manifest method.
• If any of the required VCS binaries can't be found on the $PATH. (This is obviously escalated to an error if the vcs turns out to be needed by an actual dependency)
• If a project being prefetched does not exist upstream. (Prefetching doesn't necessarily guarantee that the project will be required - e.g., it's coming from an old lock).
• If a project in the result set does not exist upstream. (Can happen if it was originally in the lock...I guess?)
• If an upstream repository has a different type than what's in the cache (so, presumably, upstream changed) - e.g., git -> hg
• If a tag moves. That is, something else suggests the tag should point to rev X, but it's now at rev Y. This could happen either with a lock, or with the central cache. The essential problem is the same, but the point where we're handling it is vastly different.
• If a source type without immutability properties comes into use, at all. (I'm lookin' at you, Subversion.)
• If a project-local package name is given in the ignore list, but does not exist in the PackageTree
• If the import graph proceeds through a package that is marked as 'ignored' by a dependency's manifest
• If a solve with targeted updates completes successfully, but fails to advance the version of a project targeted for update
• If ListPackages() encounters a directory which it lacks the permissions to enter
• If a (bare) revision in a Lock does not exist in the corresponding source, forcing it to be discarded
• If a local repo was determined to be corrupt (recover from corrupt repos #596) and was automatically cleared and recreated
• If source cache lock file is busy (as introduced in source_manager.go handle locking better #853)
• If an import was classified as stdlib, but no corresponding package appears under $GOROOT
• If an import uses a case variant that is different than the canonical case variant, but does not touch any packages in a way that necessarily induces a failure

Copied from original issue: sdboyer/gps#77

[matjam]

need a warning if the source cache lock file is busy.

[matjam]

So I can see there's a Ctx passed around that has an Out and Err var, but this Ctx isn't exposed to lower level stuff like the NewSourceManager() func.

NewSourceManger() doesn't return anything, and we don't pass anything to it.

We could make a struct in gps and assign the Out and Err to that, and then use that Ctx in parts of gps that need to provide warning output. Warnings should always be STDERR. I'm unsure as I don't know how people feel about package-wide vars.

Not sure if that's appropriate but thats my initial naive suggestion.

Might be useful to have a quiet mode? Not sure.

[bradleyfalzon]

If someone in the next week or so wants to discuss this in more detail and wants a hand playing with this, I'll be happy to assist. I think this is important to progress as I've come across a few cases where some output would've helped me understand what went wrong.

[sdboyer]

@bradleyfalzon ack, i'm sorry, i totally missed your comment on this :/ i'd be happy to chat about what's involved with this.

[bradleyfalzon]

Sorry, @sdboyer should've pinged again. I had a couple weeks off of work to work on projects, but back soon so just want to finish off my other work. I did have a quick look based on @matjam's comments, and it looks OK but requires threading throughout and I don't quite have the time to do that from start to finish this week.