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.
toplevel
.catapult_build
.common/
We have some rules on directory structure to add consistency and avoid overloaded python imports.
x
is a toplevel directory, x/__init__.py
does not exist. Directories in common/
do not have this restriction.common
should centralize all their path computation and sys.path manipulation in their master init file (example).x/x_build/
tracing/tracing/base/math.html
is /tracing/base/math.html
for an HTML import, and tracing/tracing/base/math.py
is tracing.base.math
in python.x/bin
. 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 .py
extension.$catapult/bin/run_dev_server
; and have per-project bin/run_dev_server_tests
scripts.$catpult/catapult_build
instead of $catapult/build
.