715188 - refine Talos installation workflow

Status: RESOLVED FIXED

(Testing :: Talos, defect)

Description

[Jeff Hammel]

Currently, getting set up for running Talos tests is something like
this:

https://wiki.mozilla.org/Buildbot/Talos#Running_locally_-_Source_Code

setup.py is supposed to fetch pageloader, but this does not work
correctly (bug 709340 and bug 701490).

In addition, there is a INSTALL.py script
(http://hg.mozilla.org/build/talos/file/tip/INSTALL.py) which does the
following:

1. creats a virtualenv, talos-env by default
2. fetches talos either via `hg clone` or from a zip
3. installs talos into this environment

While this is great installing from the web
(http://hg.mozilla.org/build/talos/file/5f202f20f7d8/INSTALL.py#l8),
this is not the desired effect if you already have a version of talos.

Instead the (proposed) workflow is as follows:

1. the developer gets talos via hg or otherwise
2. the developer runs INSTALL.py
2.a. INSTALL.py creates a virtualenv in the same directory it is in
2.b. INSTALL.py runs `python setup.py develop` with the virtualenv python
2.c. INSTALL.py fetches pageloader and installs it (and perhaps other
things if we have further needs)

This has the advantage of being more explicit and doing less magical
things in setup.py (with the corresponding disadvantage that you won't
be able to `easy_install` talos effectively since it depends on
pageloader). In any case, INSTALL.py is just a recipe for helping to
get things going and for more extensive use cases you can use `python
setup.py develop` directly (assuming you know what you're doing). 

This may be a good pattern to start adopting for other software as well.

Comment 1

[cmtalbert]

(In reply to Jeff Hammel [:jhammel] from comment #0)
> 2.a. INSTALL.py creates a virtualenv in the same directory it is in
If you do this, then be sure to include the virtualenv directories in your .hgignore so that they aren't tracked by the vcs cause that will confuse potential contributors who are trying to fix things in talos.

> This may be a good pattern to start adopting for other software as well.
Whatever we do, all the tools should work the same way.  So be sure you like what we're doing and that it will apply well to other cases.

Comment 2

[Jeff Hammel]

(In reply to Clint Talbert ( :ctalbert ) from comment #1)
> (In reply to Jeff Hammel [:jhammel] from comment #0)
> > 2.a. INSTALL.py creates a virtualenv in the same directory it is in
> If you do this, then be sure to include the virtualenv directories in your
> .hgignore so that they aren't tracked by the vcs cause that will confuse
> potential contributors who are trying to fix things in talos.

Of course :)

> > This may be a good pattern to start adopting for other software as well.
> Whatever we do, all the tools should work the same way.  So be sure you like
> what we're doing and that it will apply well to other cases.

+1, constrained by pragmatism; IMHO, easy_install $(TOOL) (or python setup.py develop) is a better pattern when applicable.  It leaves it to the developer to create their virtualenv, but at the same time it also allows them to manage the process (since we have at least 3 strong opinions on the "correct" way of doing this just in the A*Team, I think having Mozilla or python community consensus is not going to happen).  But Talos is special.  It requires the pageloader.xpi so has to fetch that (and there's more for mobile: https://wiki.mozilla.org/Mobile/Fennec/Android#talos ). But yeah, I think the general pattern is

1. get code (presumedly with `hg clone`)
2. run `python INSTALL.py` which a. makes a virtualenv; b. runs `python setup.py develop`; c. does anything else required for installation (which could be nothing)

And for developers that want more control, `python INSTALL.py` is just a recipe (that is, it should not be a replacement for setup.py; it is for stuff beyond the scope of setup.py).  

I personally prefer having the ability to point to a line like

python <(curl http://hg.mozilla.org/build/talos/raw-file/tip/INSTALL.py)
# http://hg.mozilla.org/build/talos/file/5f202f20f7d8/INSTALL.py#l8

However, as I said in comment 0 this doesn't support the "more traditional" workflow of checking out the code first.  I wouldn't mind supporting both methods, but IRC conversations with jmaher and wlach have convinced me otherwise.  However, if we wanted to rethink this, that is easily doable too.

Comment 3

[Jeff Hammel]

It might also be worthwhile seeing what other people do here and keeping a list of approaches.  However, from a casual survey this seems a grab bag.

Comment 4

[Jeff Hammel]

Attachment: WIP

untested code, but illustrates the basic pattern i'm going for;  i'll refine, test, and modify .hgignore and put up a patch, but if anyone has feedback in the interim about the basic pattern

Comment 5

[Jeff Hammel]

Attachment: improved install script

Comment 6

[Jeff Hammel]

pushed: http://hg.mozilla.org/build/talos/rev/9485dda3dcbb

https://wiki.mozilla.org/Buildbot/Talos#Running_locally_-_Source_Code should be updated

Comment 7

[Jeff Hammel]

drat, i forgot to remove the installation of the .xpi from setup.py :(

http://hg.mozilla.org/build/talos/file/9485dda3dcbb/setup.py#l63

Comment 8

[Jeff Hammel]

(In reply to Jeff Hammel [:jhammel] from comment #7)
> drat, i forgot to remove the installation of the .xpi from setup.py :(
> 
> http://hg.mozilla.org/build/talos/file/9485dda3dcbb/setup.py#l63

This doesn't cause any problems, but it wastes bandwidth and is silly

Comment 9

[Jeff Hammel]

Attachment: remove setup.py functionality; this is now covered in INSTALL.py and is redundant (AND doesn't work ;)

Comment 10

[Jeff Hammel]

pushed: http://hg.mozilla.org/build/talos/rev/de761a6183df