tree a70daf3065f76a0c15ef2f2c1b1e19f6eb5cd544
parent a08ee21f4b13d11863f8fa4f4f13b1cf597d7a78
author Todd Wang <toddw@google.com> 1448155100 -0800
committer Todd Wang <toddw@google.com> 1448155100 -0800

jiri: Get rid of project.JiriRoot, and many uses of JIRI_ROOT

Now that we have jiri.X to hold all our jiri-related state, we
can start putting useful stuff there.  The CL is the first step:
get rid of project.JiriRoot, and make all of our utilities use
jiri.X.Root instead of the environment variable.

There's lots of code changes scattered throughout.  Here's some
of the larger themes:

1) Replace many functions in project/paths.go with similar
methods on jiri.X that don't need to return errors.

2) Move FakeJiriRoot from jiri/project to jiritest.  That code
should never be used in production.  We can clean up
FakeJiriRoot more and use it more widely, but we'll do that
separately.

3) Also add jiritest.NewX_DeprecatedEnv, to cater to tests that
actually rely on JIRI_ROOT pointing to a valid development
tree.  As the naming suggests, we'll get rid of that function,
but for now it's good enough to isolate it so that it's
obvious it's only used in tests.

4) Remove spurious setting and resetting of the JIRI_ROOT envvar
from many tests.  We set and reset it via FakeJiriRoot, as
well as jiritest.NewX, so this behavior is now isolated.

5) Rewrite the mailer to use v.io/x/lib/cmdline, and to follow
our other conventions for jiri.X.

After this CL, the production code only refers to jiri.X.Root to
find the root directory, and that's always initialized at tool
start-up.  This means we'll be able to safely transition to the
fs-walking logic, and it'll only happen once.  All the code that
uses the root is also simpler, since we don't need error checks.

There is one exception.  The profiles code needs to access the
jiri root directory to set up default flag values, and that runs
in an init func before main, and before we have a jiri.X.  This
code now uses jiri.FindRoot, which is a best-effort that doesn't
return any errors.  It's better not to panic in tool init funcs,
since otherwise the user can't get help for a command if
JIRI_ROOT isn't set.  With the new behavior, if a user hasn't set
JIRI_ROOT the flag defaults will be wrong, but if they try to run
any command they'll still get an error that JIRI_ROOT isn't set,
so the flag defaults don't matter.

MultiPart: 1/2

Change-Id: I1368498a57b6543d6c264a1d92495395cad07f0e