Skip to content
This repository has been archived by the owner on Feb 3, 2018. It is now read-only.

Systematic support for "warnings" #77

Open
13 tasks
sdboyer opened this issue Jul 26, 2016 · 1 comment
Open
13 tasks

Systematic support for "warnings" #77

sdboyer opened this issue Jul 26, 2016 · 1 comment

Comments

@sdboyer
Copy link
Owner

sdboyer commented Jul 26, 2016

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 - Ignore directories for which we lack perms in ListPackages #154
  • If a (bare) revision in a Lock does not exist in the corresponding source, forcing it to be discarded

Related to #20

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants