The goal of this library is to help developers build more robust systems for academia as well as industry by avoiding configuration errors.
This is achieved by providing a library to build dynamic but typesafe configurations.
- Configuration checking through pydantic
- Super simple integration of alternatives for ablation studies
- Automatic CLI generation
- Better visibility which parameters were used and which not
- Testing of existing configurations to help maintain them
- No more bad awakings when a script fails because of wrong configuration
- Tracking of which configuration parameters were used and which not
- Easy and structured way to run ablation studies
There are multiple ways to set a value in the configuration. Conflicts are resolved in the following order (sorted in ascending order).
- Declaration Default (These should avoided in the first place and should always be overwritten by the configuration)
- Config Default
- Set as preset (either through cli or in config file)
- Set through config file
- Set through CLI
- Set in code before parsing
- Set in code after parsing (Can be prohibited by using pydantics (Faux Imutablility)[https://pydantic-docs.helpmanual.io/usage/models/#faux-immutability] This is meant to reflect most common use cases.
pip install -e .- pydantic
- MNIST
- examples/Demo.ipynb
- Easier integration of
- classes
- functions
- libraries
- Own cli parser for better support
- Integrate into testing frameworks
- Fast Presets: Same kind of parameters as a specific class, just about hyperparameters
- click-style execution?
- Ablation Study
- Different namespaces for subclasses? For example, class2 inherits from class2, should they have a separate or joined namespace. See test.
- Should build method be abstract? Is there a use case, where a ChildConfig
does not need a build method?
- versioneer
- Automatic testing on push
- black?
- push to pypi
- Write README
- Document Code
- Setup read the docs