Add passthru arg support in the new options system.

Review Request #1270 — Created Nov. 1, 2014 and submitted

benjyw
pants
6863646...
pants-reviews
ity, jsirois, zundel

Anything after a double-dash is captured as-is. Future changes will
plumb them through to tasks that want them.

This is useful e.g., for passing args through to a tool invoked by a task.

Ran option tests. CI running.

IT
  1. lgtm - has awesome future uses.

  2. 
      
ZU
  1. I hate to rain on this party because I think this would be a boon to the 'run' goal, but we have a current use for -- in goal_runner.py and it is important for maven style repos, so we need to find a way to handle both cases.

    In the case of a directory with the same name as a goal, it is impossible to disambiguate them as either a target or a goal without some special syntax. For example, assume a maven layout like:

    ./binary/BUILD
    ./binary/src/main/java/Main.java
    

    what should the following command do?

    pants goal compile bundle
    

    Currently, we assume that any string that matches a goal is a goal, so it will see 'bundle' as a goal. there are no targets, so the command won't do much of anything but will report SUCCESS. When we last visited this, we added some smarts so that if we also detect a directory with a BUILD file, we spit out a message. The current instructions are to disambiguate with double dash to separate goals from targets:

    ./pants goal compile -- bundle
    

    But we could do something else, like suggest:

    ./pants goal compile bundle:
    ./pants goal compile ./bundle
    ./pants goal compile bundle:bundle
    
    1. ./bundle and //bundle are both 1 character less than -- bundle and the ./bundle even tab completes - that makes it seem superior to -- bundle on the basis of not liking to type. I am in favor of pushing ./bundle a d //bundle as a result but clearly this will cause API breakage for folks who type -- bundle today.

      Beyond the bonus of 1 less character to express an ambiguous target, this would bring back the traditional CLI meaning of -- afaict, which is extra un-interpreted args for some lower tool.

    2. correction, my example above should have been:

      ./bundle/BUILD
      ./bundle/src/main/java/Main/java
      

      I am not aware of any conflicts we have today at Square, so I don't think anyone here is likely to have to change behavior. I am find with re purposing -- for its more traditional CLI meaning, but we need to update goal_runner.py too.

  2. 
      
JS
  1. 
      
  2. src/python/pants/option/arg_splitter.py (Diff revision 1)
     
     

    To attach docs I like this gizmo:

    class SplitArgs(namedtuple('SplitArgs', ['scope_to_flags', 'targets', 'passthru'])):
       """The result of splitting args.
       ...
       """
    
    1. That is nice. Changed.

  3. src/python/pants/option/arg_splitter.py (Diff revision 1)
     
     

    The docs say this returns a SplitArgs

    1. Ah yes, it works because the caller treats the return value like a regular tuple, fixed.

  4. 
      
BE
JS
  1. 
      
  2. perhaps './pants test //test' for completeness

  3. 
      
ZU
  1. Ship It!

  2. 
      
BE
BE
Review request changed

Status: Closed (submitted)

Change Summary:

Submitted as 0a071c9e0d7827ce874c479651263dddfba9b8d0.
Loading...