Add --show-invalid-targets option

Review Request #1768 — Created Feb. 14, 2015 and discarded

zundel
pants
zundel/show-invalid-targets
1099
pants-reviews
benjyw, jsirois, nhoward_tw, patricklaw

This adds a global option to show the targets that are being invalidated in the build cache.

In order to get this working in tests, I had to figure out a way to keep this options check from
raising an exception from TestOptionValues(). To do this, I implemented __contains__ in both OptionValues and TestOptionValues.

Appends the target name to the console output when an invalid target is found as follows:

$ PANTS_DEV=1 ./pants compile ./examples/src/java/com/pants/examples/protobuf/imports --show-invalid-targets
 ...
10:18:29 00:02     [protoc]
                   Invalidated 1 target.
                     examples/src/protobuf/com/pants/examples/imports:imports
JS
  1. Would the global verbose logging settings suffice here?  I have a hard time drawing a line on which detailed logging bit gets it own flag.  Since the need for detailed logging is hopefully limited to developers hacking or debugging a strange case, I lean towards a single verbose logging incantation turning it all on.  The developer can handle all the noise.
    1. Do you mean -ldebug? This isn't just for debugging pants, although it could be used for that.

    2. OK I admit it. In in this case, YES, I am using it to debug pants.

    3. OK - so I think just -ldebug as a trigger is enough.  You may or may not realize the targets are already logged.  Hidden for console, but they show ('targets' is linked and can be expanded) in the `./pants server` web console.
    4. I'm not entirely sure I agree, John. I certainly agree that for debugging-type logging, we should just have one flag that's mega-verbose. However, I can certainly imagine our users appreciating the ability to flip on verbose "what did I invalidate?" logging by modifying their .pantsrc or adding a cmdline flag.

      I like this change and I'm in favor of keeping it. However, I wonder--why force this to be global? Since it's called on a Task method, we always have an instance in hand. Users could either set it globally, or they could set it more granularly as a normal scoped option. Personally I would love to turn this on for only a few of our tasks internally by default so users always have a little more intuition for how much a given change invalidates.

    5. Don't forget that the options system in principle allows setting the logging level per-task:

      ./pants -ldebug compile <target>
      vs.
      ./pants compile -ldebug <target>
      or
      ./pants compile.java -ldebug <target>

      We don't currently implement the logging level this way, but it wouldn't be hard to.

    6. As long as -ldebug implies the more specific subset, I like having it as a more specific subset.

  2. 
      
ZU
Review request changed

Status: Discarded

Change Summary:

Dropping this. pants server is working OK for me.

Loading...