Quickunderstanding State Customization¶
Plugins¶
State plugins are features/bso-containers themselves with some differences. The following points are vague rules or maybe just concepts in progress, so feel free to make up your own mind, discuss, change them …and maybe have another coffee:
- The state plugins are (so far) mainly assigned to
state.maintenanceas they mostly would serve infrastructural tasks. But e.g.state.params.constantsis the first plugin to already have broken this rule…. so it is a state in progress. - State plugins are instantiated in custom state scripts which import the default state with
from ignite_framework.states import state. - t.b.a.
Remenber state is a singleton, so no matter where you import state it’s always the same state. This also explains how the import sequence for creating incremental state customizations has to flow. Currently the order is:
ignite_framework.framework.framework.state –> ignite_framework.states.base_state.state –> ignite_framework.states.default_state.state –> ignite_framework.states.custom_states.cool_custom_state.cool_state
To get the general idea of a custom state check out the short but cool_custom_state.py. You can import it with:
from ignite_framework.states.custom_states import cool_state as state
# Customized default configs
print(state.configs.default_configs.cool_config)
# 'cool'
# Customized constants
print(state.params.constants.constantly_cool)
# 42
