-
-
Notifications
You must be signed in to change notification settings - Fork 41
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
What's the best way to do backwards compatibility for existing configs? #479
Comments
My ideal solution would be to keep the feature of having a sync between the source code and the CLIs, and not make up something new specific for CLIs. That is, it would be nice to adopt some deprecated standard, so that deprecated decorators are added to the code, and based on that jsonargparse runs additional logic. For example if a parameter In projects that I have worked on, there are three approaches we have taken, though they haven't used specific features of jsonargparse.
What to recommend, I am not sure. But we can brainstorm further. |
2) is what I would prefer. But how does one integrate it into the parser? Is there an extension point in |
Currently there isn't such a feature. But note that it isn't just |
Actually, there is a feature that could be used, though it wasn't intended for this: custom-loaders. You can implement a custom loader. The default yaml_load has some logic which avoids weird behaviors of All parsed values go through the loader. So depending on what is loaded, the function would need to decide if a transformation is required. |
We'll try this and report back. Only handling configs is acceptable at the moment since it's how we recommend that people interact with the program. |
If I have a CLI implementation (
before.py
) with aFoo.a
argumentpython before.py --print_config > a.yaml
Where
a.yaml
is:And then create an
after.py
file whose only difference is renaminga
tob
What's the best or recommended way to support loading
a.yaml
withafter.py
, wherea
is remapped tob
? It currently fails as expected with:Context
This is currently blocking a rename in Lightning-AI/litgpt#1156
The text was updated successfully, but these errors were encountered: