vpython: Add VirtualEnv creation package.

vpython: Add VirtualEnv creation package.

Add the "venv" package, which is responsible for creating and managing
collections of specified VirtualEnv environments.

This includes the ability to resolve, create, load, and manage (pruning)
an enviornment.

This package includes unit tests which assert the correctness of the
environment. These, in turn, leverage a few binaries (sadface). However,
the binaries are small, and this seems like a reasonable thing to do
given the subject under test.

BUG=chromium:691818
TEST=unit

Review-Url: https://codereview.chromium.org/2699063004
Committed: https://github.com/luci/luci-go/commit/af075cbfb85dba33b2fc91881e530700e3d74e46

[dnj, 2017-02-17 23:14:02]

Description was changed from

==========
Updated patchset dependency

vpython: Add VirtualEnv creation package.

Add the "venv" package, which is responsible for creating and managing
collections of specified VirtualEnv environments.

This includes the ability to resolve, create, load, and manage (pruning)
an enviornment.

This package includes unit tests which assert the correctness of the
environment. These, in turn, leverage a few binaries (sadface). However,
the binaries are small, and this seems like a reasonable thing to do
given the subject under test.

BUG=chromium:691818
TEST=unit
==========

to

==========
vpython: Add VirtualEnv creation package.

Add the "venv" package, which is responsible for creating and managing
collections of specified VirtualEnv environments.

This includes the ability to resolve, create, load, and manage (pruning)
an enviornment.

This package includes unit tests which assert the correctness of the
environment. These, in turn, leverage a few binaries (sadface). However,
the binaries are small, and this seems like a reasonable thing to do
given the subject under test.

BUG=chromium:691818
TEST=unit
==========

[dnj, 2017-02-17 23:17:41]

dnj@chromium.org changed reviewers:
+ iannucci@chromium.org

[dnj, 2017-02-17 23:17:42]

PTAL! This is part of a larger "vpython" CL set for the tool. More information
can be found in the bug, or in the linked design doc:
https://docs.google.com/document/d/1GKN7rtW6-006RbG_Ryh6vr4TpUxSxJlPSCKFLq2nO...

Total CL set is:
https://codereview.chromium.org/2703463006/ (README, protobufs)
https://codereview.chromium.org/2703793003/ (filesystem)
https://codereview.chromium.org/2700273002/ (wheel)
https://codereview.chromium.org/2705623003/ (environment spec)
https://codereview.chromium.org/2701073002/ (Python interpreter management)
https://codereview.chromium.org/2699063004/ (main VirtualEnv package)
https://codereview.chromium.org/2699223002/ (CIPD support)
https://codereview.chromium.org/2702873002/ (package entry point)
https://codereview.chromium.org/2705593003/ (main application)
https://chromium-review.googlesource.com/c/444040/ (Infra entry point)

[dnj, 2017-02-22 22:49:12]

(Ping) This one's next, but also the fun one :)

[iannucci, 2017-02-23 00:54:21]

lgtm

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go
File vpython/venv/config.go (right):

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:60: // Python is the Python interpreter to use. If empty,
one will e resolved
be

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:61: // based on the Spec and the system path.
PATH?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:75: PruneLimit int
unlimited seems like dangerous defaults here. wdyt about picking some reasonable
thresholds if these are unspecified? (and having -1 really be unlimited)

Also, I initially thought that PruneLimit meant 'maximum number of virtualenvs
to allow at any time'. Maybe "MaxPrunesPerSweep" or something?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:95: // The returned Env instance may or may octually
exist. Setup must be called
may not actually

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:105: // Use one underneath our working directory.
comment is wrong

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:106: cfg.BaseDir = filepath.Join(os.TempDir(), "vpython")
wdyt about warning if BaseDir is longer than some threshold? e.g. warn if one of
the generated shebang lines (path to python in venv) would be greater than 127
on linux or OS X, and warn if the deepest file in the venv (just assume the
longest path in the virtualenv wheel) would have a path of >260 (or whatever it
is) for windows. 

In fact, it might be best to just exit early. Better to crash here than
experience weirdness later.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:163: func (cfg *Config) envForName(name string) *Env {
is it worth checking collisions?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:187: if err := cfg.Loader.Resolve(c,
cfg.LoaderResolveRoot, packages); err != nil {
why do we need separate resolve and ensure phases? ensure (from cipd) can return
all the resolved packages.

edit: is this so we can resolve and pick a directory name first?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/prune.go
File vpython/venv/prune.go (right):

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/prune.go#n...
vpython/venv/prune.go:28: func prune(c context.Context, cfg *Config, omit
string) error {
what's omit?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/prune.go#n...
vpython/venv/prune.go:75: // Ignore hidden files.
do we have to worry about them growing unbounded?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/prune.go#n...
vpython/venv/prune.go:97: logging.Debugf(c, "Pruned %d environment(s) with %d
error(s)", totalPruned, len(allErrs))
I think this should be info (and look like `Pruned 10 (limit) with ....` in the
case it hit the limit)

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/prune.go#n...
vpython/venv/prune.go:110: return
log?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/prune.go#n...
vpython/venv/prune.go:136: if err := e.deleteLocked(c); err != nil {
does it make sense to mv this to a 'prune' folder first, and have all prune
processes opportunistically try to delete the contents of the prune folder?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/system_win...
File vpython/venv/system_windows.go (right):

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/system_win...
vpython/venv/system_windows.go:13: return filepath.Join(root, "Scripts", name)
wdyt about just having a `const BinDir = "Scripts"`? Doesn't seem like it needs
a whole function. In fact, you could probably just pick it in an init() method
to avoid having 2 extra files. Just a thought.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/test_data/...
File vpython/venv/test_data/README.md (right):

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/test_data/...
vpython/venv/test_data/README.md:16: only large binary, though. It's downloaded
directly from the Internet.
It looks like it's committed to the repo as part of this cl? TBH I'd rather just
put the test artifacts in a cipd package and ensure them as part of the test
(and have a sh script to generate new ones). It should be extremely unlikely to
fail.

This is what we're probably going to move towards for large binary testing
dependencies in chromium too, so we should get ahead of the curve.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go
File vpython/venv/venv.go (right):

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:118: // This is non-fatal if it fails.
couldn't this mean that we return and this env might get pruned if we fail here?
Should we make this fatal if we're within some threshold of the prune time for
the mtime of this flag file? e.g. if the flag has < 1hour of life left, then
touching the flag requires a lock or something?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:126: // We will be creating the Env. We will to lock around
a file for this
'will to lock'

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:141: return errors.Annotate(err).Reason("failed to create
complete flag").Err()
shouldn't we loop? at least up to some limit?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:194: // For resolution purposes, our VirtualEnv package
will be index 0.
why? why not just sort them?

The Spec_Package are the fully resolved ones, right (no ${platform}, no
tag:name)? should we assert that?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:200: pkgDir := filepath.Join(bootstrapDir, "packages")
we should make sure to delete this directory after were done, right?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:214: // Download our wheel files.
Install?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:242: return errors.Annotate(err).Reason("failed to download
packages").Err()
pro tip: errors.Annotate(nil).Reason(...).D(...).Err() == nil (and is a fast
path)

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:322: // Delete our bootstrap directory (non-fatal).
ah, this is the place we delete it

[dnj, 2017-02-23 20:38:50]

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go
File vpython/venv/config.go (right):

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:60: // Python is the Python interpreter to use. If empty,
one will e resolved
On 2017/02/23 00:54:20, iannucci wrote:
> be

Done.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:61: // based on the Spec and the system path.
On 2017/02/23 00:54:20, iannucci wrote:
> PATH?

Done.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:75: PruneLimit int
On 2017/02/23 00:54:20, iannucci wrote:
> unlimited seems like dangerous defaults here. wdyt about picking some
reasonable
> thresholds if these are unspecified? (and having -1 really be unlimited)
> 
> Also, I initially thought that PruneLimit meant 'maximum number of virtualenvs
> to allow at any time'. Maybe "MaxPrunesPerSweep" or something?

Renamed to MaxPrunesPerSweep.

TBH I think unlimited is fine. This is a documented parameter, and our Infra
binary will definitely set it.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:95: // The returned Env instance may or may octually
exist. Setup must be called
On 2017/02/23 00:54:20, iannucci wrote:
> may not actually

Done.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:105: // Use one underneath our working directory.
On 2017/02/23 00:54:20, iannucci wrote:
> comment is wrong

Done.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:106: cfg.BaseDir = filepath.Join(os.TempDir(), "vpython")
On 2017/02/23 00:54:20, iannucci wrote:
> wdyt about warning if BaseDir is longer than some threshold? e.g. warn if one
of
> the generated shebang lines (path to python in venv) would be greater than 127
> on linux or OS X, and warn if the deepest file in the venv (just assume the
> longest path in the virtualenv wheel) would have a path of >260 (or whatever
it
> is) for windows. 

I'll add an option, "MaxGeneratedPathLen". If >0, it will enforce this based on
observed longest path.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:163: func (cfg *Config) envForName(name string) *Env {
On 2017/02/23 00:54:20, iannucci wrote:
> is it worth checking collisions?

I don't think so. All operations will lock, so this should be okay even if
someone does it.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/config.go#...
vpython/venv/config.go:187: if err := cfg.Loader.Resolve(c,
cfg.LoaderResolveRoot, packages); err != nil {
On 2017/02/23 00:54:20, iannucci wrote:
> why do we need separate resolve and ensure phases? ensure (from cipd) can
return
> all the resolved packages.
> 
> edit: is this so we can resolve and pick a directory name first?

Yep.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/prune.go
File vpython/venv/prune.go (right):

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/prune.go#n...
vpython/venv/prune.go:28: func prune(c context.Context, cfg *Config, omit
string) error {
On 2017/02/23 00:54:21, iannucci wrote:
> what's omit?

Done.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/prune.go#n...
vpython/venv/prune.go:75: // Ignore hidden files.
On 2017/02/23 00:54:20, iannucci wrote:
> do we have to worry about them growing unbounded?

We shouldn't have to. If someone puts their own stuff under here, then there is
a problem; otherwise, the worst worst case is we leak lock files, which are
empty.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/prune.go#n...
vpython/venv/prune.go:97: logging.Debugf(c, "Pruned %d environment(s) with %d
error(s)", totalPruned, len(allErrs))
On 2017/02/23 00:54:20, iannucci wrote:
> I think this should be info (and look like `Pruned 10 (limit) with ....` in
the
> case it hit the limit)

Done.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/prune.go#n...
vpython/venv/prune.go:110: return
On 2017/02/23 00:54:21, iannucci wrote:
> log?

Done.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/prune.go#n...
vpython/venv/prune.go:136: if err := e.deleteLocked(c); err != nil {
On 2017/02/23 00:54:20, iannucci wrote:
> does it make sense to mv this to a 'prune' folder first, and have all prune
> processes opportunistically try to delete the contents of the prune folder?

There may be a race here with moving. ATM deletion of a directory is
synchronized off of ownership of its lock file. That should be sufficient?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/system_win...
File vpython/venv/system_windows.go (right):

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/system_win...
vpython/venv/system_windows.go:13: return filepath.Join(root, "Scripts", name)
On 2017/02/23 00:54:21, iannucci wrote:
> wdyt about just having a `const BinDir = "Scripts"`? Doesn't seem like it
needs
> a whole function. In fact, you could probably just pick it in an init() method
> to avoid having 2 extra files. Just a thought.

Meh, build-time is nicer, and I think this puts the constant into context
better.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/test_data/...
File vpython/venv/test_data/README.md (right):

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/test_data/...
vpython/venv/test_data/README.md:16: only large binary, though. It's downloaded
directly from the Internet.
On 2017/02/23 00:54:21, iannucci wrote:
> It looks like it's committed to the repo as part of this cl? TBH I'd rather
just
> put the test artifacts in a cipd package and ensure them as part of the test
> (and have a sh script to generate new ones). It should be extremely unlikely
to
> fail.
> 
> This is what we're probably going to move towards for large binary testing
> dependencies in chromium too, so we should get ahead of the curve.

ATM, this package is not bound to CIPD or our infrastructure. Adding a CIPD
package or permanent hosting path would definitely undermine that.

"Git LFS" would probably be appropriate, but I don't think we want to use that
here, nor will "gclient" tolerate it.

The total file size is <2MB, so it's not *awful*. WDYT?

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go
File vpython/venv/venv.go (right):

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:118: // This is non-fatal if it fails.
On 2017/02/23 00:54:21, iannucci wrote:
> couldn't this mean that we return and this env might get pruned if we fail
here?
> Should we make this fatal if we're within some threshold of the prune time for
> the mtime of this flag file? e.g. if the flag has < 1hour of life left, then
> touching the flag requires a lock or something?

Hm, yeah that sounds reasonable.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:126: // We will be creating the Env. We will to lock around
a file for this
On 2017/02/23 00:54:21, iannucci wrote:
> 'will to lock'

Done.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:141: return errors.Annotate(err).Reason("failed to create
complete flag").Err()
On 2017/02/23 00:54:21, iannucci wrote:
> shouldn't we loop? at least up to some limit?

I don't think so. Touching a file should be pretty soid.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:194: // For resolution purposes, our VirtualEnv package
will be index 0.
On 2017/02/23 00:54:21, iannucci wrote:
> why? why not just sort them?

Doesn't really matter. The comment isn't too useful, so I will just delete it.
This is now an implementation detail.

> The Spec_Package are the fully resolved ones, right (no ${platform}, no
> tag:name)? should we assert that?

That's a precondition, so I don't think we need to assert here.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:200: pkgDir := filepath.Join(bootstrapDir, "packages")
On 2017/02/23 00:54:21, iannucci wrote:
> we should make sure to delete this directory after were done, right?

We do, yeah. See "finalize".

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:214: // Download our wheel files.
On 2017/02/23 00:54:21, iannucci wrote:
> Install?

Done.

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:242: return errors.Annotate(err).Reason("failed to download
packages").Err()
On 2017/02/23 00:54:21, iannucci wrote:
> pro tip: errors.Annotate(nil).Reason(...).D(...).Err() == nil (and is a fast
> path)

For me, this is too much on a single line :)

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/venv.go#ne...
vpython/venv/venv.go:322: // Delete our bootstrap directory (non-fatal).
On 2017/02/23 00:54:21, iannucci wrote:
> ah, this is the place we delete it

Acknowledged.

[dnj, 2017-03-11 00:22:31]

The CQ bit was checked by dnj@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-11 00:22:37]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-11 00:25:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-11 00:25:48]

Dry run: Try jobs failed on following builders:
  Luci-go Linux Trusty 64 Tester on luci.infra.try (JOB_FAILED,
https://luci-milo.appspot.com/swarming/task/34d3909768e6af10)

[iannucci, 2017-03-11 00:37:34]

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/prune.go
File vpython/venv/prune.go (right):

https://codereview.chromium.org/2699063004/diff/40001/vpython/venv/prune.go#n...
vpython/venv/prune.go:136: if err := e.deleteLocked(c); err != nil {
On 2017/02/23 20:38:49, dnj wrote:
> On 2017/02/23 00:54:20, iannucci wrote:
> > does it make sense to mv this to a 'prune' folder first, and have all prune
> > processes opportunistically try to delete the contents of the prune folder?
> 
> There may be a race here with moving. ATM deletion of a directory is
> synchronized off of ownership of its lock file. That should be sufficient?

I'm thinking about the case where it /partially/ prunes the file (e.g. on
windows) because there's an open file handle or something. If it moves to a
trash folder and everything tries to delete the trash folder, then we won't fail
part-way while holding the lock and end up with a half-destroyed virtualenv.

https://codereview.chromium.org/2699063004/diff/100001/vpython/venv/prune.go
File vpython/venv/prune.go (right):

https://codereview.chromium.org/2699063004/diff/100001/vpython/venv/prune.go#...
vpython/venv/prune.go:30: // even if it is would otherwise be candidate for
pruning.
maybe 'keep' would be better?

https://codereview.chromium.org/2699063004/diff/100001/vpython/venv/venv.go
File vpython/venv/venv.go (right):

https://codereview.chromium.org/2699063004/diff/100001/vpython/venv/venv.go#n...
vpython/venv/venv.go:183: logging.Debugf(c, "Completion flag found! Environment
is set-up: %s", e.completeFlagPath)
we don't touch the file at all any more in this case? I think we need to
touchCompleteFlagLocked in both branches, right? Or at least do a check of the
age of stat

[dnj, 2017-03-11 01:13:46]

https://codereview.chromium.org/2699063004/diff/100001/vpython/venv/prune.go
File vpython/venv/prune.go (right):

https://codereview.chromium.org/2699063004/diff/100001/vpython/venv/prune.go#...
vpython/venv/prune.go:30: // even if it is would otherwise be candidate for
pruning.
On 2017/03/11 00:37:34, iannucci wrote:
> maybe 'keep' would be better?

Went with "forceKeep".

https://codereview.chromium.org/2699063004/diff/100001/vpython/venv/venv.go
File vpython/venv/venv.go (right):

https://codereview.chromium.org/2699063004/diff/100001/vpython/venv/venv.go#n...
vpython/venv/venv.go:183: logging.Debugf(c, "Completion flag found! Environment
is set-up: %s", e.completeFlagPath)
On 2017/03/11 00:37:34, iannucci wrote:
> we don't touch the file at all any more in this case? I think we need to
> touchCompleteFlagLocked in both branches, right? Or at least do a check of the
> age of stat

We touch it repeatedly in the keep-alive monitor goroutine, but we might as well
touch it here too. Done.

[dnj, 2017-03-11 04:48:30]

The CQ bit was checked by dnj@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-11 04:48:33]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-11 04:54:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-11 04:54:04]

Dry run: Try jobs failed on following builders:
  Luci-go Presubmit on luci.infra.try (JOB_FAILED,
https://luci-milo.appspot.com/swarming/task/34d4841142f14c10)
  Luci-go Win Tester on luci.infra.try (JOB_FAILED,
https://luci-milo.appspot.com/swarming/task/34d48411063ba010)

[dnj, 2017-03-11 06:28:02]

The CQ bit was checked by dnj@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-11 06:28:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dnj, 2017-03-11 06:36:57]

The CQ bit was checked by dnj@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-11 06:37:07]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-11 06:43:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-11 06:43:59]

Dry run: This issue passed the CQ dry run.

[dnj, 2017-03-11 06:53:59]

The CQ bit was checked by dnj@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-11 06:54:09]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-11 07:00:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-11 07:00:18]

Dry run: This issue passed the CQ dry run.

[dnj, 2017-03-11 07:02:39]

The CQ bit was checked by dnj@chromium.org

[dnj, 2017-03-11 07:02:39]

The patchset sent to the CQ was uploaded after l-g-t-m from
iannucci@chromium.org
Link to the patchset: https://codereview.chromium.org/2699063004/#ps200001
(title: "bootstrap straight out of tempdir")

[commit-bot: I haz the power, 2017-03-11 07:02:47]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-11 07:07:44]

CQ is committing da patch.

Bot data: {"patchset_id": 200001, "attempt_start_ts": 1489215759642380,
"parent_rev": "84be6ac2ed927cae79eb0a5492bd23ebc05cbe56", "commit_rev":
"af075cbfb85dba33b2fc91881e530700e3d74e46"}

[commit-bot: I haz the power, 2017-03-11 07:07:47]

Description was changed from

==========
vpython: Add VirtualEnv creation package.

Add the "venv" package, which is responsible for creating and managing
collections of specified VirtualEnv environments.

This includes the ability to resolve, create, load, and manage (pruning)
an enviornment.

This package includes unit tests which assert the correctness of the
environment. These, in turn, leverage a few binaries (sadface). However,
the binaries are small, and this seems like a reasonable thing to do
given the subject under test.

BUG=chromium:691818
TEST=unit
==========

to

==========
vpython: Add VirtualEnv creation package.

Add the "venv" package, which is responsible for creating and managing
collections of specified VirtualEnv environments.

This includes the ability to resolve, create, load, and manage (pruning)
an enviornment.

This package includes unit tests which assert the correctness of the
environment. These, in turn, leverage a few binaries (sadface). However,
the binaries are small, and this seems like a reasonable thing to do
given the subject under test.

BUG=chromium:691818
TEST=unit

Review-Url: https://codereview.chromium.org/2699063004
Committed:
https://github.com/luci/luci-go/commit/af075cbfb85dba33b2fc91881e530700e3d74e46
==========

[commit-bot: I haz the power, 2017-03-11 07:07:49]

Committed patchset #11 (id:200001) as
https://github.com/luci/luci-go/commit/af075cbfb85dba33b2fc91881e530700e3d74e46