"params" is interpreted differently in section vs workload entires in
the agenda; previously, this was handled in the generic entry
construciton function by examining the ID prefix of the entry to
distinguish between the two.
This is unreliable as the user may specify their own IDs that won't have
the expected prefixes. To handle this, the "params" alias resolution for
sections is now handled in section specific part of entry processing
(workloads are handled autmatically because that is the default for
the corresponding JobConfig config point).
Changing the way target descriptions work from a static mapping to
something that is dynamically generated and is extensible via plugins.
Also moving core target implementation stuff under "framework".
Changing the way target descriptions work from a static mapping to
something that is dynamically generated and is extensible via plugins.
Also moving core target implementation stuff under "framework".
Added 3 decorators to enabled methods to be executed conditionally:
- Once for each method instance.
- Once for each class.
- Only once per environment including any derived classes.
Added execution control allowing for different environments to
be used in order to determine how often decorated commands should be ran.
Added relevant unittests for the above decorators.
This had moved to now be done by plugin cache so it has been removed
from wlauto.core.configuration.configuration and any referenced to it
have been changed to use plugin cache instead.
Renamed `__configuration` to `config_points` and in the case of
RunConfiguration it was split into `config_points` and `meta_data`
where `meta_data` contains config points for run meta data like
project name/stage ect.
WA2 only supported a single config file but the way WA3's configuration
parser works there can be as many and the user needs. They will be prioritied
in the order they are specified. e.g in `wa run agenda.yaml -c 1.yaml -c 2.yaml`
`1.yaml` will be applied first and `2.yaml` will be applied on top of that.
Both AgendaParser and ConfigParsers wrap exceptions with a a message
saying what source of configuration caused the exception. AgendaParser
uses ConfigParser within its load method, this leads to the "Error in foo"
message appearing twice. This lets AgendaParser turn of the wrapping
in ConfigParser
Previously `aliases` was conflated with global_aliases. This commit
fixes this.
`global_alias`'s are a name that can be used in top level configuration
and set the values of one or more plugin parameters that use the same
global_alias.
`aliases` is a list of alternative names for a configuration point.
Currently this is only used for instrumentation/instruments and
workload_name/name but in the future it will likely be used when
parameters have to be renamed to be more meaningful but still
maintain backward compatibility.
- Fixed merge_result_processors_instruments not merging result_processors
- Made AgendaParser have the same load/load_from_path interface as ConfigParser
- Removed source from error messages because its already predended when caught
- AgendaParser no longer needs to be passed a ConfigParser, it makes its own instance
- Changed quote style from "Error in {}" message to match other errors
- Removed `output_directory` ConfigurationPoint, it should be set and passed
by whatever instanstiates RunConfiguration.
- Made `device` a mandatory configuration point.
- Added serialization
- Now handles merging specific and generic config
`output_directory` should be set and passed why what ever instanstiates RunConfiguration.
- Removed `finalize`, replaced it with `validate`
- Added `to_pod` and `from_pod` methods
- `set` and `update_config` now take (and forward) `check_mandatory`
