-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Easier configurability of callbacks that should always be present in LightningCLI #7964
Easier configurability of callbacks that should always be present in LightningCLI #7964
Conversation
Codecov Report
@@ Coverage Diff @@
## master #7964 +/- ##
=======================================
- Coverage 92% 87% -5%
=======================================
Files 203 203
Lines 13151 13156 +5
=======================================
- Hits 12042 11412 -630
- Misses 1109 1744 +635 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice! this seems very useful
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot @mauvilsa
Can you also use this PR to mention that the config can be passed directly through CLI?
python script.py --config='{"trainer": {"callbacks": [{"class_path": "pytorch_lightning.callbacks.EarlyStopping", ...}]}}'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Minor comment
This is amazing! The only thing that is missing as far as I can tell is showing how to change the default arguments. You often want to set a particular default that is different from the class constructors. For example, in your problem you may want to swap out the |
@@ -48,6 +48,7 @@ def __init__(self, *args, parse_as_dict: bool = True, **kwargs) -> None: | |||
self.add_argument( | |||
'--config', action=ActionConfigFile, help='Path to a configuration file in json or yaml format.' | |||
) | |||
self.callbacks = [] | |||
|
|||
def add_lightning_class_args( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about adding in a place to override default arugments here? It would make sense for code locality. Then something like
def add_lightning_class_args(
self,
lightning_class: Union[Type[Trainer], Type[LightningModule], Type[LightningDataModule]],
nested_key: str,
class_defaults: Dict[str, Any] = None,
subclass_mode: bool = False
) -> None:
"""
Adds arguments from a lightning class to a nested key of the parser
Args:
lightning_class: Any subclass of {Trainer, LightningModule, LightningDataModule, Callback}.
nested_key: Name of the nested namespace to store arguments.
subclass_mode: Whether allow any subclass of the given class.
class_defaults: Set to override class defaults
"""
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added to the example in the docs an override of a default to illustrate how it could be done right now. Adding a class_defaults
argument to add_lightning_class_args
is a good idea. But this only makes sense if it works well with the subclass_mode
option. Certainly can be done, but requires work and I can't do this today.
Co-authored-by: Ethan Harris <[email protected]>
- Added change of defaults in docs
What does this PR do?
Based on a discussion in slack it seemed convenient in
LightningCLI
to have callbacks that should always be present and be configurable. This only required a small change such thatLightningArgumentParser.add_lightning_class_args
also support callbacks and the callbacks added by this method be automatically added to the trainer. How to use it is explained in lightning_cli.rst.Before submitting
PR review
Anyone in the community is free to review the PR once the tests have passed.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:
Did you have fun?
Make sure you had fun coding 🙃