Merge branch 'master' of https://github.com/felixludos/omni-fig

paper.md

@@ -41,14 +41,14 @@ Project organization and configuration is an important albeit unglamourous part
 
 Perhaps the most similar to our proposed `omni-fig`, is `hydra` [@hydra], which is a popular configuration framework that provides a feature-rich user interface, even including composing config files to some extent. However, from the developer's perspective, the project structure of `hydra` is more constrained and the configuration system is built on top of `OmegaConf` [@omegaconf] making more advanced features such as automatic instantiation of objects nonexistent or more cumbersome. Packages such as `OmegaConf` or `pydantic` [@pydantic] on the other hand, focus more on integrations and performance, but lack high-level features and a user-friendly interface. Slightly less comparable, are a variety of packages designed for more specific applications with fixed project structures, such as `dynaconf` [@dynaconf], `gin-config` [@ginconfig] or `confr` [@arro2022confr]. Finally, there are some built-in libraries that are commonly used for the command-line interface and configuration, such as `argparse` [@argparse] or `configparser` [@configparser]. However, these provide minimal features and scale poorly to more complex, evolving projects.
 
-All too often, the trade-off between power and simplicity results in software (particularly research projects) containing cutting edge features bearly perceptable behind a limited or even nonexistent user interface. Here a good project configuration framework can bridge the gap between developers and users. The user wants to select functionality in a concise and intuitive way while still allowing fine-grained control when needed.
+All too often, the trade-off between power and simplicity results in software (particularly research projects) containing cutting edge features barely perceptable behind a limited or even nonexistent user interface. Here a good project configuration framework can bridge the gap between developers and users. The user wants to select functionality in a concise and intuitive way while still allowing fine-grained control when needed.
 Neanwhile, the developer first and foremost wants the configuration system to seamlessly provide the necessary parameters without interfering with the broader design and implementation of the functionality.
 
 # Summary
 
 Here `omni-fig` strikes a favorable balance in that it was designed from the ground up to cater specifically to the needs of both the *developer* and the *user*.
 
-The primary way the *developer* interacts with `omni-fig` is by registering any functionality as a `script` (for functions), `component` (for classes), or `modifier` (for mixins), creating config files as needed, and then accessing config parameters using the at runtime. Once registered, the objects can be accessed anywhere in the project through the config object, thereby incentivizing the developer to register any functionality that can be customized by configuration. Meanwhile, since config files can easily be composed, the developer is incentivized to separate configuration into a modular way. Finally at runtime, the developer doesn't have to worry about how the config parameters are specified (e.g. as a command line argument or in a config file), but can simply access them through the config object. This abstraction allows arbitrarily complex objects, even including mix-ins added dynamically at runtime (see `modifier`), to be instantiated automatically.
+The primary way the *developer* interacts with `omni-fig` is by registering any functionality as a `script` (for functions), `component` (for classes), or `modifier` (for mixins), creating config files as needed, and then accessing config parameters using the [missing word] at runtime. Once registered, the objects can be accessed anywhere in the project through the config object, thereby incentivizing the developer to register any functionality that can be customized by configuration. Meanwhile, since config files can easily be composed, the developer is incentivized to separate configuration in a modular way. Finally at runtime, the developer doesn't have to worry about how the config parameters are specified (e.g. as a command line argument or in a config file), but can simply access them through the config object. This abstraction allows arbitrarily complex objects, even including mix-ins added dynamically at runtime (see `modifier`), to be instantiated automatically.
 
 From the user's perspective, the modular config files and explicit registration of top-level functionality greatly improves the transparency of the project. For example, just by running `fig -h`, a custom help message displays all registered scripts in the project. Then the high-level modularity of the config files allows the developer to effortlessly create demos by composing existing config files to showcase the key features of the project.