Pinning dependencies in requirements.txt

[abidlabs]

For gradio, here is what I did with each external dependency:

• aiofiles: the first post-zero release was 22.x. I confirmed gradio's /file route works with audio files for this version of aiofiles so I allow 22.x, 23.x
• aiohttp: the current major (3.x) is >5 years old, so I've just pinned to 3.x
• altair: just released 5.0 in May. Gradio works with both 4.x and 5.x so I've pinned to 4.x or 5.x
• fastapi: still a pre-release so I haven't pinned
• ffmpy: still a pre-release so I haven't pinned
• httpx: still a pre-release so I haven't pinned
• Jinja2: we've had issues before between jinja2 and starlette compatibilties so I didn't want to pin too aggressively. The current version is 3.1.2 (released more than a year ago), I just pinned <4.0. This shouldn't have much of an effect
• markdown-it-py and mdit-py-plugins -- didn't pin these because I'm hoping we can remove these dependencies altogether as a result of Render Markdown and LaTeX in gr.Markdown and gr.DataFrame in the frontend, like gr.Chatbot #4523
• pygments -- unused dependency! removed
• matplotlib -- the current major (3.x) is >15 years old, so I've just pinned to 3.x
• numpy -- the current major (1.x) is >15 years old, so I've just pinned to 1.x
• orjson -- the current major (3.x) is >3 years old, so I've just pinned to 3.x
• pandas -- I confirmed gradio works with 1.x, 2.x so I pin those
• PIL -- I confirmed gradio works from 8.0 (>3 years old) onwards so I pin anything between 8.x to 10.x. PIL is actively released so this is one that we'd want to keep track of and expand the pinned range if they release 11.0
• pydantic -- the source of our troubles. @freddyaboulton has confirmed that pydnatic 1.x and 2.x are supported in the latest version of gradio so I've pinned those
• python-multipart: still a pre-release so I haven't pinned
• pydub: still a pre-release so I haven't pinned
• pyyamml -- I confirmed gr.load() works with tabular examples with 5.x, 6.x so I pin those
• requests -- the current major (2.x) is >9 years old, so I've just pinned to 2.x
• semantic_version -- the current major (2.x) is >10 years old, so I've just pinned to 2.x
• uvicorn: still a pre-release so I haven't pinned (beyond the existing pin)
• websockets: already pinned to >=10.0. Added a pin <12.0

For gradio_client:

• requests -- made same change as for gradio
• websockets -- made same change as for gradio
• packaging - I didn't pin this library because we use it in a very basic way and they release new majors every year
• fsspec - pretty much same situation as packaging
• typing_extensions -- pined to 4.x
• httpx: still a pre-release so I haven't pinned

Separately, I also added:

• typing_extensions
• packaging

as requirements to gradio since we use them explicitly in the gradio source code. Safer to include them rather than depend on them being available from gradio_client since the client source code may change.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
gradio	✅ Ready (Inspect)	Visit Preview	Jul 12, 2023 11:52pm

[gradio-pr-bot]

All the demos for this PR have been deployed at https://huggingface.co/spaces/gradio-pr-deploys/pr-4885-all-demos

---

You can install the changes in this PR by running:

pip install https://gradio-builds.s3.amazonaws.com/d48f463cd4f8745b687b9fd5a96bbcb245cbf101/gradio-3.36.1-py3-none-any.whl

[gradio-pr-bot]

🎉 Chromatic build completed!

There are 0 visual changes to review.
There are 0 failed tests to fix.

• Storybook Preview
• Build Review

[freddyaboulton]

Thanks for going through this abidlabs. Since we're only pinning to majors that were released at least a couple of years ago I think this will not cause unintended upgrade/downgrades of dependencies in developer's environments. Would be good to communicate to developers that we're making this change though?

[freddyaboulton]

Nit: Let's use the same pin as fastapi. Version 1.0 is actually not allowed.

[abidlabs]

Interesting. Do we have to do this? I don't think we need to use the same versions of fastapi (that's a bit redundant anyways since fastapi is one our dependencies). We just need to make sure that our library's use of pydantic is valid according to the version of pydantic we've pinned.

That being said, I haven't tested different versions of pydantic so maybe we actually do need to be more strict

[abidlabs]

Would be good to communicate to developers that we're making this change though?

Yeah good point, I'll add a note in the breaking changes, and let's post on Twitter + Discord when we do the next release.

[akx]

Was there an issue or something tracking why this is needed for so many packages? Overly tight pins will cause issues in downstream projects utilizing Gradio – and furthermore, not all Python packages do Semver at all, so pinning to a major version may not mean what you expect.

[abidlabs]

Hi @akx yes, the issue was that pydantic released 2.0, which included breaking changes that broke a large number of Gradio apps. See #4835

I agree that pinned dependencies can cause downstream conflicts, which is why we've kept the pins pretty loose -- it's mostly future-proofing. We'll need to keep an eye out for new releases of our dependencies and update pins as needed, but we're expecting this PR to be better for the long-term stability of Gradio apps.

[abidlabs]

Updated pins and improved changelog message @freddyaboulton -- I think this PR should be good to go

[freddyaboulton]

Thanks for the nice PR @abidlabs !!