fetch.py: Use '--nohooks' when calling 'gclient sync'

fetch.py: Add '--nohooks' option.

'fetch chromium' will fail if the build dependencies are not already installed
on the host machine, because it runs 'gclient sync' which, by default, will run
hooks that will try to run build/gyp_chromium (which will then fail).

This introduces a --nohooks option that solve the problem by allowing the
user to do the following:

  1) fetch --nohooks <recipe>
  2) src/build/install-build-deps.sh
  3) fetch <recipe>

BUG=325795
TEST=Run 'fetch --nohooks chromium' in a temporary 'clean' chroot directory.
R=maruel@chromium.org,jochen@chromium.org,scottmg@chromium.org,agable@chromium.org

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=240680

[M-A Ruel, 2013-12-05 14:45:17]

Deflecting to Robbie.

[agable, 2013-12-09 22:22:14]

On 2013/12/05 14:45:17, M-A Ruel wrote:
> Deflecting to Robbie.

See my comments here: https://codereview.chromium.org/107703002/, I think this
is a bad idea. Not lgtm until convinced otherwise.

[digit1, 2013-12-11 13:47:47]

On 2013/12/09 22:22:14, Aaron Gable wrote:
> On 2013/12/05 14:45:17, M-A Ruel wrote:
> > Deflecting to Robbie.
> 
> See my comments here: https://codereview.chromium.org/107703002/, I think this
> is a bad idea. Not lgtm until convinced otherwise.

Thanks, I've changed the patch to add a --nohooks option to fetch.py instead.
Can you tell me if you're ok with it?

[agable, 2013-12-11 17:30:12]

I think this LGTM. The purist in me dislikes giving the fetch command line
explicit knowledge of the projects it is working on, but I've long since
abandoned the idea that fetch.py is truly the best long-term solution here. It
will be replaced by wyk eventually, so this is fine by me.

+Dirk Pranke since he was also looking at the other CL.

[Dirk Pranke, 2013-12-11 19:53:23]

lgtm. A couple of minor issues that could be cleaned up.

https://chromiumcodereview.appspot.com/106403003/diff/20001/fetch.py
File fetch.py (right):

https://chromiumcodereview.appspot.com/106403003/diff/20001/fetch.py#newcode36
fetch.py:36: Options = collections.namedtuple('Options', ['dryrun', 'nohooks'])
You could just import optparse and create an optparse.Values() object down on
line 246 instead of doing this (see comment there).

https://chromiumcodereview.appspot.com/106403003/diff/20001/fetch.py#newcode125
fetch.py:125: self.run_gclient(gclient_cmd)
It seems like you have a type conflict here; gclient_cmd is either a string or a
list of strings . I'm not seeing how that would work, but even if it does, it's
at best confusing.

https://chromiumcodereview.appspot.com/106403003/diff/20001/fetch.py#newcode246
fetch.py:246: return Options(dryrun=dryrun, nohooks=nohooks), recipe, props
This could just be:

  return optparse.Values({'dryrun': dryrun, 'nohooks': nohooks}).

and then you wouldn't need the namedtuple.

[digit1, 2013-12-13 15:26:21]

https://chromiumcodereview.appspot.com/106403003/diff/20001/fetch.py
File fetch.py (right):

https://chromiumcodereview.appspot.com/106403003/diff/20001/fetch.py#newcode125
fetch.py:125: self.run_gclient(gclient_cmd)
It's either a string or a tuple, and this works due to the way run_gclient
works. I agree it's a bit confusing, so I've changed it to something more
explicit (for the record, passing a list crashes at runtime).

https://chromiumcodereview.appspot.com/106403003/diff/20001/fetch.py#newcode246
fetch.py:246: return Options(dryrun=dryrun, nohooks=nohooks), recipe, props
I've done that, however:

- The Python documentation states that optparse is deprecated
  starting from 2.7, do we really want to use it here for something
  that simple?

- The Values() constructor is not documented by the official
  documentation either. I trust what you say though.

[Dirk Pranke, 2013-12-13 16:59:16]

On 2013/12/13 15:26:21, digit1 wrote:
> https://chromiumcodereview.appspot.com/106403003/diff/20001/fetch.py
> File fetch.py (right):
> 
>
https://chromiumcodereview.appspot.com/106403003/diff/20001/fetch.py#newcode125
> fetch.py:125: self.run_gclient(gclient_cmd)
> It's either a string or a tuple, and this works due to the way run_gclient
> works. I agree it's a bit confusing, so I've changed it to something more
> explicit (for the record, passing a list crashes at runtime).
> 

Hm; odd. I'll have to stare at that further to understand why it works.

>
https://chromiumcodereview.appspot.com/106403003/diff/20001/fetch.py#newcode246
> fetch.py:246: return Options(dryrun=dryrun, nohooks=nohooks), recipe, props
> I've done that, however:
> 
> - The Python documentation states that optparse is deprecated
>   starting from 2.7, do we really want to use it here for something
>   that simple?
> 
> - The Values() constructor is not documented by the official
>   documentation either. I trust what you say though.

We use optparse everywhere and argparse nowhere; I think it's fine to use
optparse.Values. At some point we'll need to switch over to argparse, but we can
worry about that later. 

However, it's not a big deal; namedtuples are fine, too.

[commit-bot: I haz the power, 2013-12-13 17:05:33]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/digit@chromium.org/106403003/40001

[commit-bot: I haz the power, 2013-12-13 17:07:36]

Change committed as 240680