1178158 - properly package mochitest

Status: NEW

(Testing :: Mochitest, defect)

Description

[Julien Pagès (:parkouss)]

it would be good to package properly mochitest, and maybe put it on pypi.

There are multiple advantages to do that, like clearly identify mochitest dependencies and be able to run tests without a complete mozilla-central tree.

Comment 1

[(not currently active) Ted Mielczarek]

We talked about this on IRC a little bit. I don't see much point to this as its own goal. Mochitest is very much tied to the Gecko codebase, and is not a cross-browser test harness, so distributing it outside of mozilla-central doesn't buy us anything. bug 775756 was tracking the work to move our harneses to use mozbase instead of automation.py, I think we fixed everything except the Android harnesses.

Comment 2

[Julien Pagès (:parkouss)]

I think the main goal of :ahal with this idea was to clean up mochitest python runner.

For now, automationutils.py is still used in there (see bug 1027119), along with automation.py for the Android harnesses (as you mentionned).

Maybe we don't need to package mochitest in a python standard way. Still it is a good idea to try to clean this up (refactoring + reordering files in packages), and removing *external* dependencies is a part of this task I think (avoid tight coupling).

Once we got there, making a setup.py file is pretty easy. This has the advantage to be installable in a virtualenv easily for example.

As you say, upload mochitest to pypi may have not much sense, but I think that structuring the code like a real python program makes sense.

Comment 3

[(not currently active) Ted Mielczarek]

(In reply to Julien Pagès from comment #2)
> Maybe we don't need to package mochitest in a python standard way. Still it
> is a good idea to try to clean this up (refactoring + reordering files in
> packages), and removing *external* dependencies is a part of this task I
> think (avoid tight coupling).

This I fully agree with. If you'd like to work on removing automation.py.in or automationutils.py I'd be happy to offer advice!

Comment 4

[Andrew Halberstadt [:ahal]]

Packaging is not the same thing as uploading to pypi. I agree there is probably no benefit to uploading to pypi, but making it a package may make it easier for mach to install it into a virtualenv properly (instead of using sys.path hacks).

But that benefit is small. The main thing is that the harness gets restructured into something sane, which can be done with or without packaging. In other words I agree, no need to focus on packaging yet, but it might be something to look at if we ever fix bug 985141.

Comment 5

[(not currently active) Ted Mielczarek]

I think with automationutils.py gone we ought to be able to get rid of the sys.path hacks and invoke runtests.py directly from the source directory. The only fiddly bit might be figuring out the test path, but we know where the manifest is and we can just point it at the root manifest.