Based on MMEngine's [Registry](registry.md) and [Config](config.md), users can build modules across libraries.
For example, use [MMClassification](https://github.com/open-mmlab/mmclassification)'s backbones in [MMDetection](https://github.com/open-mmlab/mmdetection), or [MMDetection](https://github.com/open-mmlab/mmdetection)'s data transforms in [MMRotate](https://github.com/open-mmlab/mmrotate), or using [MMDetection](https://github.com/open-mmlab/mmdetection)'s detectors in [MMTracking](https://github.com/open-mmlab/mmtracking).
Modules registered in the same registry tree can be called across libraries by adding the **package name prefix** before the module's type in the config. Here are some common examples:
## Use backbone across libraries
Taking the example of using MMClassification's ConvNeXt in MMDetection:
Firstly, adding the `custom_imports` field to the config to register the backbones of MMClassification to the registry.
Secondly, adding the package name of MMClassification `mmcls` to the `type` of the backbone as a prefix: `mmcls.ConvNeXt`
```python
# Use custom_imports to register mmcls models to the registry
Using an algorithm from another library is a little bit complex.
An algorithm contains multiple submodules. Each submodule needs to add a prefix to its `type`. Take using MMDetection's YOLOX in MMTracking as an example:
```python
# Use custom_imports to register mmdet models to the registry
To prevent adding prefix to all of the submodules manually, the `_scope_` keyword is introduced. When the `_scope_` keyword is added to the config of a module, all submodules' scope will be changed by the `_scope_` keyword. Here is an example config:
```python
# Use custom_imports to register mmdet models to the registry