Closed danbraunai-apollo closed 9 months ago
Nicest version of this might be a function that takes a config object and a temp_dir, then converts the config to yaml itself.
Just thought some more on it, I think an even nicer version is just to have the "main" function in all the scripts take a Config object as an argument. Then have the entrypoint to the script be fire.Fire(some_other_function), where some_other_function takes in a filepath to a yaml, converts it to a Config, then calls the main function with that config. In all the tests we'd call main and not some_other_function.
Though we might want to reserve the "main" naming for the highest-level function (the one that does preprocessing and calls the long function in the script).
Could also overload main
to take either a path to a config or a config object. I don't know how fire.Fire works with overloaded fns, though.
While I'm refactoring this anyways, do we want to support passing in arbitrary kwargs in the command line to modify the config? e.g. python run_lm_rib_build.py modular_arithmatic.yaml --dtype float64
. I'm weakly in favor, and think it's pretty easy with fire.
do we want to support passing in arbitrary kwargs in the command line to modify the config? e.g. python run_lm_rib_build.py modular_arithmatic.yaml --dtype float64. I'm weakly in favor, and think it's pretty easy with fire.
I have quite a strong NO vote for this. I've seen multiple instances of this feature go wrong, where configs don't match up because of the kwargs. It also just makes it harder to share configs around for running experiments
I have quite a strong NO vote for this. I've seen multiple instances of this feature go wrong, where configs don't match up because of the kwargs. It also just makes it harder to share configs around for running experiments
Seems reasonable! Happy to defer to you here.
In the tests we have dirty stuff like this:
But, as Nix wrote in his parallelization PR, we can just do: