armi.apps module

The base ARMI App class.

This module defines the App class, which is used to configure the ARMI Framework for a specific application. An App implements a simple interface for customizing much of the Framework’s behavior.

Historical Fun Fact

This pattern is used by many frameworks as a way of encapsulating what would otherwise be global state. The ARMI Framework has historically made heavy use of global state (e.g., armi.nucDirectory.nuclideBases), and it will take quite a bit of effort to refactor the code to access such things through an App object. We are planning to do this, but for now this App class is somewhat rudimentary.

class armi.apps.App

Bases: object

The main point of customization for the ARMI Framework.

The App class is intended to be subclassed in order to customize the functionality and look-and-feel of the ARMI Framework for a specific use case. An App contains a plugin manager, which should be populated in __init__() with a collection of plugins that are deemed suitable for a given application, as well as other methods which provide further customization.

The base App class is also a good place to expose some more convenient ways to get data out of the Plugin API; calling the pluggy hooks directly can sometimes be a pain, as the results returned by the individual plugins may need to be merged and/or checked for errors. Adding that logic here reduces boilerplate throughout the rest of the code.

This mostly initializes the default plugin manager. Subclasses are free to adopt this plugin manager and register more plugins of their own, or to throw it away and start from scratch if they do not wish to use the default Framework plugins.

For a description of the things that an ARMI plugin can do, see the armi.plugins module.

name = 'armi'

The program name of the app. This should be the actual name of the python entry point that loads the app, or the name of the module that contains the appropriate __main__ function. For example, if the app is expected to be invoked with python -m myapp, name should be "myapp"

property version: str

Grab the version of this app (defaults to ARMI version).

Notes

This is designed to be over-ridable by Application developers.

property pluginManager: armi.pluginManager.ArmiPluginManager

Return the App’s PluginManager.

getSettings() → Dict[str, armi.settings.setting.Setting]

Return a dictionary containing all Settings defined by the framework and all plugins.

getParamRenames() → Dict[str, str]

Return the parameter renames from all registered plugins.

This renders a merged dictionary containing all parameter renames from all of the registered plugins. It also performs simple error checking. The result of this operation is cached, since it is somewhat expensive to perform. If the App detects that its plugin manager’s set of registered plugins has changed, the cache will be invalidated and recomputed.

registerUserPlugins(pluginPaths)

Register additional plugins passed in by importable paths. These plugins may be provided e.g. by an application during startup based on user input.

Format expected to be a list of full namespaces to plugin classes. There should be a comma between individual plugins and dots representing the file path or importable python namespace.

Examples

importable namespace: armi.stuff.plugindir.pluginMod.pluginCls,armi.whatever.plugMod2.plugCls2

or on Linux/Unix: /path/to/pluginMod.py:pluginCls,/path/to/plugMod2.py:plugCls2

or on Windows: C:\path\to\pluginMod.py:pluginCls,C:\\path\to\plugMod2.py:plugCls2

Notes

These paths are meant to be taken from a settings file, though this method is public. The idea is that these “user plugins” differ from regular plugins because they are defined during run time, not import time. As such, we restrict their flexibility and power as compared to the usual ArmiPlugins.

property splashText

Return a textual splash screen.

Specific applications will want to customize this, but by default the ARMI one is produced, with extra data on the App name and version, if available.