-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor config #2266
Refactor config #2266
Conversation
…run configuration
…onary a bit more explicit Instead of implicit through the use of lru_cache
Since the reload logic no longer relies on any state, the relevant loop is simple enough that it feels clearest to include it in the main entry point file.
This should make things like the color palette and frame size more easily customizable.
And likewise DEFAULT_MOBJECT_TO_MOBJECT_BUFFER -> DEFAULT_MOBJECT_TO_MOBJECT_BUFF
It's a bit silly to have it's valued defined by camera_config, when it's only function is to be a default value for Camera's configuration
It may become a bit unwieldy to make sure this matches the structure of default_config, given the amount of code repetition involved. It seems easier for a user to just create their own custom_config.yml file directly.
Just as a suggestion, it'd be amazing to squash-merge PRs as it's otherwise a bit difficult to keep track of what changed in Manim on the |
Configuration was a bit of a mess, this is an attempt to clean it up and better clarify what's going on.
At a high level, the default_config.yml file should be where all configuration defaults are set, determining default parameters for various classes, constants, or other specifications a user may want to change. They can then create their own custom_config.yml file to update any of these to their own personal taste (for instance mine lives here).
Note, for anyone who had a custom_config.yml file, this update will require that it be updated to a new format
The configuration from these files is loaded into a global dictionary, named manim_config, which is also updated based on the CLI arguments.
Previously, a lot of configuration that used CLI arguments, or these yml files, was a bit spread out an unsystematic. Here the aim is for configuration associated with specific classes to be clearly marked as such, and for code relevant to processing that configuration (e.g. for Window) to lie within the class itself.
Other updates