Catapult is intended to be a set of performance tools, mostly based on tracing, for developers of Chromium and other software to analyze that software’s performance. It has a lot of supporting libraries and tooling to make this happen. We’d like to create an organizational structure that makes it easy to find the performance tooling developers want, and hard to accidentally depend on something internal. Furthermore, we’d like to make it easy for code in catapult to eventually grow to its own repo, when possible. To that end, we use these guidelines to decide where code should live.
We have some rules on directory structure to add consistency and avoid overloaded python imports.
xis a toplevel directory,
x/__init__.pydoes not exist. Directories in
common/do not have this restriction.
commonshould centralize all their path computation and sys.path manipulation in their master init file (example).
/tracing/base/math.htmlfor an HTML import, and
bin/must not be a module, e.g. contain
__init__.py, as such a name would create namespace conflicts. Executable files should not have a
$catapult/bin/run_dev_server; and have per-project
Catapult supports two types of tests:
bin/run_dev_server_testspython executable like this.
bin/run_py_testsexecutable like this.
Both types of tests should be added to the configuration in build_steps.py. Please see the comments in that file for full documentation on specifying test commands, arguments, disabled platforms, and required environment variables.