A cube is structured as follows:
mycube/ | |-- data/ | |-- cubes.mycube.css | |-- cubes.mycube.js | `-- external_resources | |-- debian/ | |-- changelog | |-- compat | |-- control | |-- copyright | |-- cubicweb-mycube.prerm | `-- rules | |-- entities.py | |-- i18n/ | |-- en.po | |-- es.po | `-- fr.po | |-- __init__.py | |-- MANIFEST.in | |-- migration/ | |-- postcreate.py | `-- precreate.py | |-- __pkginfo__.py | |-- schema.py | |-- setup.py | |-- site_cubicweb.py | |-- hooks.py | |-- test/ | |-- data/ | | `-- bootstrap_cubes | |-- pytestconf.py | |-- realdb_test_mycube.py | `-- test_mycube.py | `-- views.py
We can use subpackages instead of python modules for views.py, entities.py, schema.py or hooks.py. For example, we could have:
mycube/ | |-- entities.py |-- hooks.py `-- views/ |-- __init__.py |-- forms.py |-- primary.py `-- widgets.py
At least you should have the file __pkginfo__.py.
It contains metadata describing your cube, mostly useful for packaging.
Two important attributes of this module are __depends__ and __recommends__ dictionaries that indicates what should be installed (and each version if necessary) for the cube to work.
Dependency on other cubes are expected to be of the form ‘cubicweb-<cubename>’.
When an instance is created, dependencies are automatically installed, while recommends are not.
Recommends may be seen as a kind of ‘weak dependency’. Eg, the most important effect of recommending a cube is that, if cube A recommends cube B, the cube B will be loaded before the cube A (same thing happend when A depends on B).
Having this behaviour is sometime desired: on schema creation, you may rely on something defined in the other’s schema; on database creation, on something created by the other’s postcreate, and so on.