-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Removing .update and get_config, attempt 2 #5240
Conversation
🪼 branch checks and previews
Install Gradio from this PR pip install https://gradio-builds.s3.amazonaws.com/e7abb0c95d7a0cd37048170982018d5f440a5134/gradio-3.44.4-py3-none-any.whl Install Gradio Python Client from this PR pip install "gradio-client @ git+https://github.com/gradio-app/gradio@e7abb0c95d7a0cd37048170982018d5f440a5134#subdirectory=client/python" |
🦄 change detectedThis Pull Request includes changes to the following packages.
With the following changelog entry.
|
We should update this section in the Guides: https://www.gradio.app/guides/blocks-and-event-listeners#updating-component-configurations |
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.
The new update logic is awesome. Definitely much simpler and I think will work well with custom components.
I see a shortcoming with the proposed get_config change in that it won't get the props from a parent class. For example, Chatbot currently doesn't list the selectable prop in the config but before it did. Also there are some component props that are not listed in the init constructor like bokeh_version for the plots. Will think about this today.
gradio/blocks.py
Outdated
return hasattr(context.thread_data, "blocks") | ||
|
||
|
||
def updateable(fn): |
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 can automatically wrap the init with updateable in a metaclass so that custom component authors don't even have to worry about this when creating their own components 👀
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.
was trying to think how to do this. Not familiar with metaclasses, will take a look!
Good point. Just to add -- this is actually a potential bug currently in |
Agree with @freddyaboulton's suggestions. Tested
I don't think its been deprecated yet just fyi. I don't see any warnings when using the Component.update() methods In your previous PR, you had implemented:
Just to confirm, sending configs to the backend so that they affect the preprocessing/postprocessing is not part of this PR, right? E.g. import gradio as gr
def update_image_type():
print("updated")
return gr.Image(type="filepath")
with gr.Blocks() as demo:
i = gr.Image()
t = gr.Textbox()
btn = gr.Button()
btn.click(update_image_type, None, i)
i.change(lambda x:x, i, t)
demo.launch() does not work
|
We could still have components implement their own get_configs, which return the extra parameters plus a call to super()? Something like def get_config(self):
return {
"selectable": self.selectable,
...super().get_config()
}
Yes sorry not planning on making the deprecation as part of this PR because of the next comment
Yep, I'll do this in a subsequent PR, trying to keep things smaller and more testable. So for that reason, not deprecating or even adding this to the guide yet. |
Yea I think that makes sense! Although in the specific case of selectable, I think it should be added to the config automatically if the component is selectable without users having to worry about it. |
.changeset/many-tips-create.md
Outdated
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 need to make the changeset thing support multiline comments for fix + feat. I'll do that tomorrow, should be quick.
Overrode get_config in these two cases to restore these config variables. Scanning through the rest of the components I couldn't find any other cases where the config had additional fields. |
I'm still seeing an error with Once the plot components are fixed and tested -- should be good to merge in! |
Still seeing one issue @aliabid94 -- will Slack you |
Trying a different approach (much simpler!!!) to removing get_config and update.
get_config is removed, the config used is simply any attribute that is in the Block that shares a name with one of the constructor paramaters.
update is not removed for backwards compatibility, but deprecated. Instead return the component itself. Created a
updateable
decorator that simply checks to see if we're in an update, and if so, skips the constructor and wraps the args and kwargs in an update dictionary. easy peasy.