Open Bug 1178158 Opened 4 years ago Updated 4 years ago

properly package mochitest

Categories

(Testing :: Mochitest, defect)

defect
Not set

Tracking

(firefox42 affected)

Tracking Status
firefox42 --- affected

People

(Reporter: parkouss, Unassigned)

References

(Depends on 1 open bug)

Details

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.
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.
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.
(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!
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.
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.
You need to log in before you can comment on or make changes to this bug.