Enable the use of system python in testing.

Enable the use of system python in testing.

BUG=

[Paweł Hajdan Jr., 2013-06-03 18:28:19]

https://codereview.chromium.org/16117004/diff/1/net/test/python_utils.cc
File net/test/python_utils.cc (right):

https://codereview.chromium.org/16117004/diff/1/net/test/python_utils.cc#newc...
net/test/python_utils.cc:112: dir =
base::FilePath(FILE_PATH_LITERAL("python.exe"));
Could you explain more how and why you're using this?

Note that on Windows there is no real concept of "system" programs or libraries
(except ones that come from Microsoft).

[msimonides, 2013-06-04 06:22:23]

On 2013/06/03 18:28:19, Paweł Hajdan Jr. wrote:
> https://codereview.chromium.org/16117004/diff/1/net/test/python_utils.cc
> File net/test/python_utils.cc (right):
> 
>
https://codereview.chromium.org/16117004/diff/1/net/test/python_utils.cc#newc...
> net/test/python_utils.cc:112: dir =
> base::FilePath(FILE_PATH_LITERAL("python.exe"));
> Could you explain more how and why you're using this?
> 
> Note that on Windows there is no real concept of "system" programs or
libraries
> (except ones that come from Microsoft).

We want to avoid bundling third_party/python_26 with each test build of our
product. With this addition it is possible to use the Python installation
available in the PATH (I agree "system" is not the best choice of word).

[Paweł Hajdan Jr., 2013-06-04 17:58:54]

On 2013/06/04 06:22:23, msimonides wrote:
> We want to avoid bundling third_party/python_26 with each test build of our
> product. With this addition it is possible to use the Python installation
> available in the PATH (I agree "system" is not the best choice of word).

Users of the test build would need to set up python.exe anyway in a non-standard
way (since there is none on Windows).

Not only is location of python.exe important, but afaik you also need python
modules in the right location (or are they "inlined" into the .exe?).

Could you explain more about distributing the test build and why exactly you
don't want python_26 in it?

Note that you can consider removing third_party/python_26 and instruct the users
to put python there...

[msimonides, 2013-06-05 09:14:24]

On 2013/06/04 17:58:54, Paweł Hajdan Jr. wrote:
> On 2013/06/04 06:22:23, msimonides wrote:
> > We want to avoid bundling third_party/python_26 with each test build of our
> > product. With this addition it is possible to use the Python installation
> > available in the PATH (I agree "system" is not the best choice of word).
> 
> Users of the test build would need to set up python.exe anyway in a
non-standard
> way (since there is none on Windows).
> 
> Not only is location of python.exe important, but afaik you also need python
> modules in the right location (or are they "inlined" into the .exe?).
> 
> Could you explain more about distributing the test build and why exactly you
> don't want python_26 in it?
> 
> Note that you can consider removing third_party/python_26 and instruct the
users
> to put python there...

Here is more background:
in order to slim down the size of the whole package of the build and tests we
have a custom tool to pack only the necessary files. This includes test data
files and some python modules from third_party. In our company having Python 2.6
in system path (regardless of the operating system) is basically a must. That's
why for us it was an "obvious" size optimization to avoid packing the python_26
directory and use the distribution that is already installed. Therefore I have
made this patch to be able to switch from python in third_party to the
distribution installed elsewhere in the system.

So these are our reasons for this change.

Also note that in non-Windows systems it is possible to use a different python
version just by changing the PATH environment variable. Enabling the
"use_system_python_in_tests" option adds this flexibility to Windows as well
(this is more of a philosophical argument than a practical one though).

[Paweł Hajdan Jr., 2013-06-05 18:58:06]

> in order to slim down the size of the whole package of the build and tests we
> have a custom tool to pack only the necessary files. This includes test data
> files and some python modules from third_party.

How much do you save by removing third_party/python_26?

> Also note that in non-Windows systems it is possible to use a different python
> version just by changing the PATH environment variable. Enabling the
> "use_system_python_in_tests" option adds this flexibility to Windows as well
> (this is more of a philosophical argument than a practical one though).

I wonder if it's possible to do the same on Windows - could you try launching
just python.exe with third_party/python_26 at the end of PATH? I think that'd be
a better solution than adding more build options.

[msimonides, 2013-06-06 08:46:37]

On 2013/06/05 18:58:06, Paweł Hajdan Jr. wrote:
[...]
> I wonder if it's possible to do the same on Windows - could you try launching
> just python.exe with third_party/python_26 at the end of PATH? I think that'd
be
> a better solution than adding more build options.

This is a good idea.
Even if relative paths in PATH won't work I can always build an absolute one and
append it to environment.
It will be a bit more code changes though, especially that base::LaunchOptions
doesn't seem to allow setting the environment on Windows. I guess I should use
CreateProcess directly in net/test/spawned_test_server/local_test_server_win.cc.
Currently I have a few tasks of higher priority so I'll get back to you in some
time, when I try it out.

[Daniel Bratell, 2013-08-01 12:18:42]

On 2013/06/06 08:46:37, msimonides wrote:
> On 2013/06/05 18:58:06, Paweł Hajdan Jr. wrote:
> [...]
> > I wonder if it's possible to do the same on Windows - could you try
launching
> > just python.exe with third_party/python_26 at the end of PATH? I think
that'd
> be
> > a better solution than adding more build options.
> 
> This is a good idea.
> Even if relative paths in PATH won't work I can always build an absolute one
and
> append it to environment.
> It will be a bit more code changes though, especially that base::LaunchOptions
> doesn't seem to allow setting the environment on Windows. I guess I should use
> CreateProcess directly in
net/test/spawned_test_server/local_test_server_win.cc.
> Currently I have a few tasks of higher priority so I'll get back to you in
some
> time, when I try it out.

Alternative solution implemented in https://codereview.chromium.org/21537002