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
where :
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.