Plumb new-style options into the Context.

Review Request #1102 — Created Oct. 1, 2014 and submitted

benjyw
pants
e19090b...
pants-reviews
jsirois, patricklaw, zundel

Allows code to reference option values the new way.

Renamed the overloaded self.options in Command to self.old_options/self.new_options,
to avoid confusion. Previously these collided and the only reason it worked was that
self.options happened to be reset to the right one just before using it.

Change a single flag reference to use the new path, as proof that it works.

With this change we can not only register flags the new way but also reference the option
values the new way. Once everything is ported to use these, we can switch the parser to
the new one, and the transition will be complete.

ci baking.

PA
  1. 
      
  2. src/python/pants/goal/context.py (Diff revision 1)
     
     

    old_options ?

    1. +1

    2. I've changed the name of the argument and the member, but I can't change the name of the property because it's referenced all over the place.

  3. src/python/pants/goal/context.py (Diff revision 1)
     
     

    ditto above--should the name reflect oldness? Or is it too ubiquitously used for this change?

    1. Yep, too ubiquitous:

      git grep 'context.options' | wc -l
      193

  4. 
      
ZU
  1. I am more in favor of renaming all of the legacy stuff to 'old_options' or 'legacy_options' than I am calling the new options system 'new_options'. The old options system will always be old or legacy, but the new system you are introduction won't always be new. We need to make sure we go back and rename every field we've named 'new_options' when we are done or things will look silly (add TODOs?)

  2. rename to old_options

  3. 
      
BE
ZU
  1. Ship It!

  2. 
      
BE
Review request changed

Status: Closed (submitted)

Loading...