-
Notifications
You must be signed in to change notification settings - Fork 15
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
[dev] Config Registration Functions in __init__.py #72
base: main
Are you sure you want to change the base?
Conversation
Before merging, I just want to point out that because of the way pytorch structures its files (and hydra_configs.torch.optim.register() however, losses and data-related must be done like this: hydra_configs.torch.nn.modules.register()
hydra_configs.torch.utils.data.register() For now it's not possible to do: hydra_configs.torch.nn.modules.loss.register() because Semantically, registering optimizers with I'm open to ideas for ameliorating this semantic ambiguity. |
from .loss import BCELossConf | ||
from .loss import BCEWithLogitsLossConf | ||
from .loss import CosineEmbeddingLossConf | ||
from .loss import CTCLossConf | ||
from .loss import L1LossConf | ||
from .loss import HingeEmbeddingLossConf | ||
from .loss import KLDivLossConf | ||
from .loss import MarginRankingLossConf | ||
from .loss import MSELossConf | ||
from .loss import MultiLabelMarginLossConf | ||
from .loss import MultiLabelSoftMarginLossConf | ||
from .loss import MultiMarginLossConf | ||
from .loss import NLLLossConf | ||
from .loss import NLLLoss2dConf | ||
from .loss import PoissonNLLLossConf | ||
from .loss import SmoothL1LossConf | ||
from .loss import SoftMarginLossConf | ||
from .loss import TripletMarginLossConf |
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.
feels like this would better be inside loss.py and __init__.py
would just call it from its register function.
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.
It makes sense there, but loss.py
is a configen output. This is manual code.
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.
maybe we should create a convention:
loss.py # generated
loss_handcoded.py # manual additions.
At this point, the __init__.py
file can import them both (and possibly also export from both, making them appear like one file).
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.
not a bad idea. I think we need a convention for handling manual configs anyways.
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.
here is an even better idea.
We can add support to custom import to configen at the top and the bottom of the generated configs.
Allowing automatic import of user provided files if they exist.
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.
Could you elaborate on this?
Do you mean chain the 'manual' file to the 'generated' one through importing that is automatically added by configen if a field is passed in the configen conf yaml?
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.
not exactly.
I mean importing if a file with a specific name exists.
generated/foo.py
try:
from . import foo_header
except ImportError:
pass
# generated code here
try:
from . import foo_footer
except ImportError:
pass
This way, you can add manual foo_footer.py and foo_header.py files that will get imported automatically when the user imports foo.py.
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.
Overall looks okay.
implements config registration for
optim
via__init__.py
If this looks good, I'll broadcast the same strategy across the rest of the configs we currently have.
Partially Addressing #53