Breaking Changes in Gradio 4.0

[abidlabs]

Gradio 4.0 is a new major version, and includes breaking changes from 3.x. Here's a list of all the breaking changes, along with migration steps where appropriate. You can also find this information in our changelog: https://www.gradio.app/changelog

Breaking changes related to components:

• Removes **kwarg from every component, meaning that components cannot accept arbitrary (unused) parameters. Previously, warnings would be thrown.
• Removes deprecated parameters. For example, plain is no longer an alias for secondary for the variant argument in the gr.Button class
• Removes the deprecated Carousel class and StatusTracker class and Box layout class
• Removes the deprecated Variable alias for State
• Removes the deprecated .style() methods from component classes
• Removes the deprecated .update() method from component classes. Instead, you can now just return an instance of a component from your function. I.e. return gr.Textbox(lines=4) instead of gr.Textbox.update(lines=4)
• Removes get_interpretation_neighbors() and get_interpretation_scores() from component classes
• Removes deprecation.py -- this was designed for internal usage so unlikely to break gradio apps
• Moves save to cache methods from component methods to standalone functions in processing_utils
• Renames source param in gr.Audio and gr.Video to sources
• Removes show_edit_button param from `gr.Audio``

Other changes related to the gradio library:

• Removes the deprecated status_tracker parameter from events
• Removes the deprecated HuggingFaceDatasetJSONSaver class
• Now Blocks.load() can only be use an is instance method to attach an event that runs when the page loads. To use the class method, use gr.load() instead
• Similarly, Interface.load() has been removed
• If you are runnin Gradio 4.x, you can not gr.load a Space that is running Gradio 3.x. However, you can still use the client libraries (see changes to the client libraries below).
• Removes deprecated parameters, such as enable_queue from launch()
• Many of the positional arguments in launch() are now keyword only, and show_tips has been removed
• Changes the format of flagged data to json instead of filepath for media and chatbot
• Removes gr.Series and gr.Parallel
• All API endpoints are named by deafult. If api_name=None, the api name is the name of the python function.

Changes related to the Client libraries:

• When using the gradio Client libraries in 3.x with any component that returned JSON data (including gr.Chatbot, gr.Label, and gr.JSON), the data would get saved to a file and the filepath would be returned. Similarly, you would have to pass input JSON as a filepath. Now, the JSON data is passed and returned directly, making it easier to work with these components using the clients.

Migrating to Gradio 4.0

Here are some concrete tips to help migrate to Gradio 4.0:

• Using allowed_paths

Since the working directory is now not served by default, if you reference local files within your CSS or in a gr.HTML component using the /file= route, you will need to explicitly allow access to those files (or their parent directories) using the allowed_paths parameter in launch()

For example, if your code looks like this:

import gradio as gr

with gr.Blocks() as demo:
    gr.HTML("<img src='/file=image.png' alt='image One'>")
    
demo.launch()

In order for the HTML component to be able to serve image.png, you will need to add image.png in allowed_paths like this:

import gradio as gr

with gr.Blocks() as demo:
    gr.HTML("<img src='/file=image.png' alt='image One'>")
    
demo.launch(allowed_paths=["image.png"])

or if you want to expose all files in your working directory as was the case in Gradio 3.x (not recommended if you plan to share your app with others), you could do:

import gradio as gr

with gr.Blocks() as demo:
    gr.HTML("<img src='/file=image.png' alt='image One'>")
    
demo.launch(allowed_paths=["."])

• Using concurrency_limit instead of concurrency_count

Previously, in Gradio 3.x, there was a single global concurrency_count parameter that controlled how many threads could execute tasks from the queue simultaneously. By default concurrency_count was 1, which meant that only a single event could be executed at a time (to avoid OOM errors when working with prediction functions that utilized a large amount of memory or GPU usage). You could bypass the queue by setting queue=False.

In Gradio 4.0, the concurrency_count parameter has been removed. You can still control the number of total threads by using the max_threads parameter. The default value of this parameter is 40, but you don't have worry (as much) about OOM errors, because even though there are 40 threads, we use a single-worker-single-event model, which means each worker thread only executes a specific function. So effectively, each function has its own "concurrency count" of 1. If you'd like to change this behavior, you can do so by setting a parameter concurrency_limit, which is now a parameter of each event, not a global parameter. By default this is 1 for each event, but you can set it to a higher value, or to None if you'd like to allow an arbitrary number of executions of this event simultaneously. Events can also be grouped together using the concurrency_id parameter so that they share the same limit, and by default, events that call the same function share the same concurrency_id.

To summarize migration:

• For events that execute quickly or don't use much CPU or GPU resources, you should set concurrency_limit=None in Gradio 4.0. (Previously you would set queue=False.)
• For events that take significant resources (like the prediction function of your machine learning model), and you only want 1 execution of this function at a time, you don't have to set any parameters.
• For events that take significant resources (like the prediction function of your machine learning model), and you only want X executions of this function at a time, you should set concurrency_limit=X parameter in the event trigger.(Previously you would set a global concurrency_count=X.)

[hieu-blackbox]

Hi @abidlabs Are there any alternatives to gr.Parallel? I need to use this feature to show comparison

[abidlabs]

Hi @hieu-blackbox you can just create a wrapper function which internally calls two or more models, and then returns their values -- and similarly, you can have a list of output components.